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 -- <file>..." to discard changes in working directory)
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
it's indeed just the pointers that changed. I was hoping that I can just revert the pointers to their previous values ...
cu
gregor
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
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
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
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
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.
[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....
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
Other suggestions? "move-submodules"?
"remaster-submodules" ?
Right. I now have a script for that, will test a bit more before
commiting it.
Robin