David Aguilar [off-list ref] writes:
quoted
After hinting a low-hanging-fruit that would be an easy way for new
people to dip their toes, I saw no takers for one month, so I ended
up doing it myself.
My bad,...
Not yours. These hints I drop from time to time are meant for eager
new people who want to dip their toes to the development (we don't
do "assignments" but these are the closest that we have); you no
longer quite qualify as "new" ;-)
While on the mergetool topic...
Now we are not talking about "dip their toes" low hanging fruit
anymore ;-)
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?
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
Am 24.08.2012 10:31, schrieb David Aguilar:
On Thu, Aug 23, 2012 at 10:39 AM, Junio C Hamano [off-list ref] wrote:
quoted
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.
I agree.
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.
Me thinks that after I successfully taught checkout to properly
recurse into submodule work trees too it should know all those
tricks. In my current version it can handle directory/submodule
conversions in both directions, this should be sufficient to
make "checkout --theirs/--ours" work properly. Note to self: add
tests for that.
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.
True. But a submodule recursing checkout would do the right thing
here too.
Afterwards, the .git file is left behind, which could cause
problems elsewhere since we really don't want a .git file
in that situation.
Hmm, either you remove all the files tracked in the submodule
together with the gitfile or you'll possibly have former submodule
files lying around there too. Recursive checkout will do all that
for you.
I'm not even sure what to do about the
.gitmodules file either.
Maybe we should issue a warning when the .gitmodules file is not
consistent with the [non]existence of a submodule in the work tree?
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).
It looks to me as if the submodule/directory conflict can be handled
by a recursive checkout without having to add something to mergetool.