Nanako Shiraishi <nanako3@lavabit.com> writes:

quoted text
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> * 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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html