On Thu, Aug 23, 2012 at 10:39 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > David Aguilar <davvid@xxxxxxxxx> writes: >> Would the ability to resolve the various merge situations using >> the command-line be a wanted addition? >> >> This would let a submodule or deleted/modified encountering >> user do something like: >> >> $ git mergetool --theirs -- submodule >> >> ...and not have to remember the various git commands that it runs. > > Does it have to run various git commands? For a normal path, all it > needs to do is "git checkout --theirs $path", no? > > What does it mean to resolve a conflicted merge of a gitlink to take > "theirs"? We obviously would want to point the resolved gitlink at > the submodule commit their side wants in the resulting index but what, > if any, should we do to the submodule itself? > > Stepping back a bit, if there is no conflict, and as a result of a > clean merge (this applies to the case where you check out another > branch that has different commit at the submodule path), if gitlink > changed to point at a different commit in the submodule, what should > happen? > > If you start from a clean working tree, with your gitlink pointing > at the commit that matches HEAD in the submodule, and if the working > tree of the submodule does not have any local modification, it may > be ideal to check out the new commit in the submodule (are there > cases where "git checkout other_branch" in the superproject does not > want to touch the submodule working tree?). > > There are cases where it is not possible; checking out the new > commit in the submodule working tree may not succeed due to local > modifications. But is that kind of complication limited to the > merge resolution case? Isn't it shared with normal "switching > branches" case as well? > > If so, it could be that your "git mergetool --theirs -- submodule" > is working around a wrong problem, and the right solution may be to > make "git checkout --theirs -- $path" to always do an appropriate > thing regardless of what kind of object $path is, no? True. Admittedly, I'm not a heavy submodule user myself so I tried crafting the directory vs submodule conflict to see what the usability is like. checkout --theirs and --ours could learn a few tricks. When trying to choose the directory in that situation I had to had to "git rm --cached" the submodule path so that git would recognize that there was no longer a conflict. That makes sense to me because I was following along by reading the mergetool code, but I don't think most users would know to "git rm" a path which they intend to keep. Afterwards, the .git file is left behind, which could cause problems elsewhere since we really don't want a .git file in that situation. I'm not even sure what to do about the .gitmodules file either. Here's the script I was using to setup the merge conflict in case anyone wants to get a feel for the usability around this edge case. Pass --submodule if you want the remote side to have a submodule. By default, the local side has a submodule and the remote side of the merge brings along a directory. That said, this really isn't an issue, per say. I first poked at it because I noticed that mergetool still needed stdin for some things. It's certainly an edge case, and perhaps this just shows that mergetool really is the right porcelain for the job when a user runs into these types of conflicts (the stdin thing really isn't an issue). #!/bin/sh if test "$1" = "--submodule" then first=with-directory second=with-submodule echo "local will be a directory, remote will be a submodule" else first=with-submodule second=with-directory echo "local will be a submodule, remote will be a directory" fi repo=submodule-conflict-$$ && echo "creating $repo" && mkdir "$repo" && cd "$repo" && git init && git commit --allow-empty -m'initial' && git checkout -b with-directory master && mkdir the-conflict && touch the-conflict/path && git add the-conflict/path && git commit -m'added path into the-conflict' && git checkout -b with-submodule master && git submodule add ./ the-conflict && git commit -m'added submodule as the-conflict' && git checkout -b tmp-merge master && git merge $first && git merge $second -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html