0

I have a submodule that is using the wrong remote and the wrong branch. I have edited the .gitmodules file in the parent git repository so have the correct url (remote) and branch. However when I use any variation of git submodule init, git submodule update, git reset --hard origin/branch, etc. from within or outside of the submodule, at worst I get an error and at best I get a confirmation that the command succeeded with no actual change to the code in the submodule's directory.

Assuming my .gitmodules is configured correctly, how do I correctly update the submodule directory so that it shows code from the correct remote/branch combination?

Update: It appears that the "branch" attribute of the submodule configuration is ignored when performing an update.

Jake
  • 7,565
  • 6
  • 55
  • 68
  • It's ignored unless you use `--remote`, `--merge`, and/or `--rebase`. – torek May 30 '16 at 00:25
  • @torek Thanks for responding but without more context I'm not sure what you're trying to say. Could you elaborate and perhaps give a specific example? – Jake May 30 '16 at 00:27
  • I don't like, and hence don't use, sobmodules, so I don't have any actual examples. Check out `git help submodule` and search for `branch` though. It's quite confusing, but it does say that `--remote` makes it act differently, and that update checks some additional settings in `submodule..update`. – torek May 30 '16 at 00:31

1 Answers1

1

By removing the submodule and doing git submodule add, see for example this other answer of mine. The issue there is not an exact duplicate but explains why just updating .gitmodules won't do the trick:

The "git submodule add" command does a couple of things:

  • It clones the submodule under the current directory and by default checks out the master branch.
  • It adds the submodule's clone path to the ".gitmodules" file and adds this file to the index, ready to be committed.
  • It adds the submodule's current commit ID to the index, ready to be committed.

So you would be missing the last step, and git submodule init/update expect the commit id to be already in place. That is why you need git submodule add.

Community
  • 1
  • 1
eis
  • 51,991
  • 13
  • 150
  • 199
  • This seems like a total hack. Based on your and @torek's resonses I am strongly considering abandoning submodules altogether. Maybe it's better to just `.gitignore` the subdirectory and use a traditional repository. My build scripts can update these as needed. – Jake May 31 '16 at 07:09
  • @Jake I don't think removing and adding a submodule conf qualifies as a hack, but I agree that there are a lot of things with submodules that do feel like hackish, and I'm not a big fan of functionality either. Some say subtrees are a better option, I personally prefer just using separate repositories. – eis May 31 '16 at 09:49
  • Maybe "hack" is the wrong word but this is analogous to "turn it off and on again" and isn't indicative of a fully implemented feature. – Jake May 31 '16 at 10:31
  • I think it's pretty much the same thing you'd do with a regular git remote - you remove the old one and add a new one. But I'm not really disagreeing you on the general point. – eis May 31 '16 at 10:51