Re: What's cooking in git.git (topics)

Nanako Shiraishi [off-list ref] writes:

Quoting Junio C Hamano [off-list ref]:

quoted

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

This needs to be merged to master iff/when merge-theirs gets merged,
but I do not think this series is widely supported, so both are on hold.

Why do you say it is not widely supported?  I may be wrong but I think
you developed these patches after somebody from the mailing list asked
for this feature.

Well, for one thing, I do not believe in their cause.  As I wrote in the
log messages for these commits (actually not these above which is a series
for merge fixup, but the other topic), I do not think it is a sensible
thing to say "let's take as much automerge results as possible to salvage
our changes where they do not overlap with what the upstream did, but I
would give up our changes to places that the upstream also touched,
because I do not understand what they did well enough to be able to
resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
that.

That also was the reason I did not add any documentation to it.  But I do
like the change to the infrastructure to allow passing strategy-specific
options through git-merge and git-pull.  Perhaps I should write something
up, if only to salvage that -X<option> part, even though I am very much
inclined to discard -Xtheirs (and -Xours) part.