On Thu, Aug 23, 2012 at 10:39 AM, Junio C Hamano <gits...@pobox.com> wrote:
> David Aguilar <dav...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
