Yeah, but that is only about the commit log message. The issue of
recording a wrong tree when commits X and Y exist is not alleviated, is
it?
No, it's not.
On the other hand, I've sometimes heard people say "when I get a merge
conflict, I'd want to discard what I did _only in the conflicted part_."
I am not sure if such a conflict resolution makes much sense in practice,
but perhaps people know that their changes are worthless crap anyway, and
do not even care about their work themselves, to the point that they would
rather discard what they did than spend more time to fix them up properly.
Whether that makes sense or not, what they want is different from "theirs"
(which is opposite of "ours"); they want to keep their own changes for
parts that did not conflict, and give up what they did only in the
conflicted part. Perhaps such a kind of mixed conflict resolution should
be supported under the name of "theirs", even though that would make
"ours" and "theirs" _not_ the opposite of each other. I dunno...
Hmm, anyway you do want to test what this strategy would do --- before
merging. The point of "ours"/"theirs" is AFAICS that they *cannot*
produce broken trees (they can cause you to lose committed stuff if used
carelessly, but the resulting tree is already in some branch and
supposedly has already been tested). So breaking the symmetry would not
be good probably.
I guess I see the reason why "ours" is more useful than "theirs". The
reason is that rebase (and "rebase -i" in particular is in some sense
different from most other git operations. Git workflows are
merge-based, so your checked-out branch is the one where the interesting
stuff is happening; if you wanted a "theirs" merge, you would probably
do it as a "ours" merge in the other branch. Rebase instead is
cherrypicking basically, so "ours" makes no sense (it would just *not*
cherrypick).
(It also explains why I saw a use case for "theirs" -- as a former arch
user, I still tend to think in terms of cherrypicks more than merges).
The correct way to proceed would be something like "git rebase -i --onto
origin/master $(git merge-base origin/master master) master", and then
if you have
A--B--C--X--Y origin/master
\
--C'--D--E master
change
pick C'
pick D
pick E
into
reset C'^
pick --strategy=theirs C'
mark :1
reset origin/master
pick :1
pick D
pick E
Then I guess the correct way to go is to write a custom script that uses
the sequencer to make the rebase scenario less dangerous. You can do
#! /bin/sh
# git-merge-after-amend <branch>
#
# Makes it possible to do a fast-forward merge of <branch>
# into HEAD, assuming that the first diverging commit of <branch>
# is an --amend'ed version of the first diverging commit of HEAD.
us=$(git rev-parse HEAD)
them=$(git rev-parse $1)
base=$(git merge-base $us $them)
(echo reset $base
first=t
git rev-list --reverse $us..$them | while read i do
if test "$first" = t; then
first=
echo pick --strategy=theirs $i
echo mark :1
echo reset $us
echo pick --edit :1
else
echo pick $i
fi
done) | git-sequencer
This script could actually become a merge strategy, so that you could do
git reset --hard origin/master
git merge -s split-first HEAD@{1}
This is maybe a little contrived (what if there are conflits, ecc.), but
I like how it shows git's pluggability.
So, as a result of the discussion, I think that:
1) it can be useful to put the "theirs" strategy into git, especially as
the sequencer (which is cherrypick-based) becomes an important component
of some git porcelain; I would remove the rebase example from my patch
and make it just a power-user option (same as "-s ours").
2) user-defined merge strategies can be useful. So it would make sense
to modify "git-merge" so that it accepts arbitrary merge strategies
instead of just the predefined ones. These would default to disallowing
fast forward and trivial merges. (Possibly, as a safety net, "index",
"base", "file", "one-file", "tree" should be excluded... this in turn
means adding an interface to the commands array in git.c... again, I can
do this -- if it is considered interesting; I'd like to know that in
advance -- after the built-in merge is committed).
3) this scenario giveit would make sense to provide the strategy option
to "git cherry-pick". I can write a patch for "git cherry-pick" if you
are interested, though I'd like to have a hint about what to do with the
short option "-s", which is already taken by "--signoff". The same
thing could be done to the sequencer's pick command, so I'm also CCing
Stephan Beyer about this.
4) A useful option for the sequencer (and possibly for git-rebase) would
be "--batch", ensuring that a single execution of the sequencer does the
entire job. "--edit" would then be changed to mean "ask user to edit
commit message" instead of "stop and let the user amend the commit"; and
if a conflict was found, the sequencer would simply abort and exit with
a non-zero exit status.
Thanks,
Paolo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
