David Aguilar <dav...@gmail.com> writes:

>> 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

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?
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

Reply via email to