# Git merge and submodules **URL:** \ **Category:** Development\ **Tags:** development\ **Created:** [January 12, 2011, 6:17pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779 "2011-01-12T18:17:02Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Gregor\_Maier](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)\ **Post date:** [January 12, 2011, 6:17pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/1 "2011-01-12T18:17:02Z")
Hi, I've got a curious problem here with git. I've merge one of my topic branches (topic/gregor/ressembler-hotfix) into another one (topic/gregor/rpc) using git merge --no-ff. This worked fine, but it also updated my submodules. When I do a git status right after the merge I get: # (use "git checkout -- \..." to discard changes in working directory) ---
**Author:** ![Jonathan\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)\ **Post date:** [January 12, 2011, 7:10pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/2 "2011-01-12T19:10:52Z")
> How I can I get rid of that. I don't really care for updating my > submodules. The "git checkout -- aux/binpac", etc. didn't help. If you just want to prevent it from showing something in `git status`, you can give it the --ignore-submodules options. There's also a global git config option you can add to your ~/.gitconfig, e.g.: [submodule "aux/binpac"]     ignore = all You'd have to add a section for each submodule you want to ignore, though. > Can I do a merge without getting the submodules as well? Just to be sure we're understanding what happened, can you check if files were actually updated in the submodules? If my understanding is right, nothing actually was updated in the submodules. What has changed are your bro repository's submodule "pointers", which essentially track a specific version (commit) of a foreign repository so that you'd checkout that version when you explicitly do a `git submodule update`. If this is the case, I'd recommend just taking the "ignore" approach I described above. > Alternatively, I guess I can just accept the changes to the submodules. > Can I just do a "git commit -a" ? That's another option, but I don't think I like it because it pollutes the commit history with a bunch of "updating submodule" type commits and I think it might also lead to the repository maintainer having to reset submodules again upon merging your branch. > However, git status still tells that I'm ahead by 7 commits? > Why? I can see that I'm ahead by 1 commit, namely the merge commit.... Sorry, don't have any good idea about why that is. Maybe compare with a fresh clone of the repository. - Jon ---
**Author:** ![Gregor\_Maier](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)\ **Post date:** [January 12, 2011, 7:26pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/3 "2011-01-12T19:26:00Z")
it's indeed just the pointers that changed. I was hoping that I can just revert the pointers to their previous values ... cu gregor ---
**Author:** ![Gregor\_Maier](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)\ **Post date:** [January 12, 2011, 11:45pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/4 "2011-01-12T23:45:41Z")
FYI "git submodule --recursive update" seems to have solved the problem. No idea what was going on there and where to wrong submodule info came from.... cu gregor ---
**Author:** ![Jonathan\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)\ **Post date:** [January 13, 2011, 4:29pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/5 "2011-01-13T16:29:48Z")
> No idea what was going on there and where to wrong submodule info came from.... It's because the two branches that were merged had differing submodule "pointers" and when the merge occurs it just changes the pointers, not the actual content of your local repositories submodules, thus `git status` has to report a change in the submodules. > "git submodule --recursive update" seems to have solved the problem. Yeah, I haven't strained myself too hard thinking about this but I think maybe this is a good solution for anyone that encounters this after doing branch merges because after the merge, submodule pointers should always be set to the most recent version between the two merging branches. i.e. it's not possible that the `git submodule update` actually checked out an older version of the submodules. On the other hand, for someone that's directly making changes to submodules, this would probably not be the command they want to run when they see similar things from `git status`. - Jon ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 13, 2011, 4:49pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/6 "2011-01-13T16:49:19Z")
Gregor and I talked yesterday about adding a simple script like "fix-submodules" that would do whatever is necessary to get the submodules into the right state (which probably is just such a recursive update; but Gregor, didn't we have a second thing the script could do as well?). So, after a merge one would just run that and be good. Another script which I think would be useful is something like "update-submodules" that moves all submodules to their most recent version (e.g., if we're in master, checks out all the other master version and commits the update). Do you think these make sense? Robin ---
**Author:** ![Jonathan\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)\ **Post date:** [January 13, 2011, 5:32pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/7 "2011-01-13T17:32:39Z")
> Gregor and I talked yesterday about adding a simple script like > "fix-submodules" that would do whatever is necessary to get the > submodules into the right state (which probably is just such a > recursive update; but Gregor, didn't we have a second thing the > script could do as well?). So, after a merge one would just run that > and be good. Yeah, I think doing a recursive update of submodules is the right thing to do after merging with another branch. But the other case (which is probably less common) is that someone may be doing work on the submodule repositories. The submodule update command for them does the wrong thing. They need to either 1) Ignore submodule changes that `git status` (i.e. don't commit submodule pointers), either with a gitconfig option or just by cautiously not adding submodule changes to commits. 2) Go ahead w/ committing submodule pointer changes In either case, the repo maintainer will make sure every submodule points to the most recent master commit after a branch is merged. Do you have an opinion for which convention we should follow? Since the same thing happens in the end, maybe it's fine to just leave it to developer preference (as long as they try to avoid spamming the commit log with purely "update submodule" type commits if they choose #2). > Another script which I think would be useful is something like > "update-submodules" that moves all submodules to their most recent > version (e.g., if we're in master, checks out all the other master > version and commits the update). Sounds useful, but mostly for use by repo maintainers, right? But the name might be confusing because it actually doesn't involve the submodule update command. - Jon ---
**Author:** ![Gregor\_Maier](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)\ **Post date:** [January 13, 2011, 5:43pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/8 "2011-01-13T17:43:40Z")
> > Gregor and I talked yesterday about adding a simple script like > > "fix-submodules" that would do whatever is necessary to get the > > submodules into the right state (which probably is just such a > > recursive update; but Gregor, didn't we have a second thing the > > script could do as well?). So, after a merge one would just run that > > and be good. > > Yeah, I think doing a recursive update of submodules is the right thing to do after merging with another branch. Exactly. I think that's the common case, that somebody just wants to work on bro itself and not be bothered with submodule changes. The idea was that such a script would make life easier for people new or not too familiar with git. > But the other case (which is probably less common) is that someone may be doing work on the submodule repositories. The submodule update command for them does the wrong thing. They need to either > [ACK] > > Since the same thing happens in the end, maybe it's fine to just leave it to developer preference (as long as they try to avoid spamming the commit log with purely "update submodule" type commits if they choose #2). ACK. I think that can be left up to the developer. > > Another script which I think would be useful is something like > > "update-submodules" that moves all submodules to their most recent > > [cut] > > [cut] > But the name might be confusing because it actually doesn't involve the submodule update command. ACK. ---
**Author:** ![Gregor\_Maier](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)\ **Post date:** [January 13, 2011, 5:46pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/9 "2011-01-13T17:46:23Z")
> [cut] but Gregor, didn't we have a second thing the > script could do as well?). git submodule init (maybe with --recursive, don't know whether it's needed) This command can be used if you cloned the repository and forgot the --recursive. (\*) The submodule init will then clone the submodule repositories and check out the appropriate version. cu Gregor (\*) This actually happened to me a couple of times. I clone the repository. Did my changes and when I tried to compile it complained that I didn't have binpac.... ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 13, 2011, 5:49pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/10 "2011-01-13T17:49:35Z")
> Since the same thing happens in the end, maybe it's fine to just leave it to developer preference (as long as they try to avoid spamming the commit log with purely "update submodule" type commits if they choose #2). Yeah, sounds right for now. If we had a reliable way to identify "update submodule" commits, the notifier script could suppress them on topic branches, but not sure how to recognize them. Otherwise, likewise ACK on the rest. > But the name might be confusing because it actually doesn't involve the submodule update command. Other suggestions? "move-submodules"? Robin ---
**Author:** ![Jonathan\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)\ **Post date:** [January 13, 2011, 5:56pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/11 "2011-01-13T17:56:09Z")
> Other suggestions? "move-submodules"? "remaster-submodules" ? ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 16, 2011, 12:52am UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/12 "2011-01-16T00:52:12Z")
Right. I now have a script for that, will test a bit more before commiting it. Robin ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:39pm UTC](https://community.zeek.org/t/git-merge-and-submodules/1779/13 "2022-05-06T15:39:23Z")