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

[David Aguilar <davvid@gmail.com>]

On Thu, Aug 23, 2012 at 10:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> 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