Re: Re*: mergetool: support --tool-help option like difftool does

On Thu, Aug 23, 2012 at 10:39 AM, Junio C Hamano [off-list ref] wrote:

David Aguilar [off-list ref] writes:

quoted

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