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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 18, 2008, 09:08 UTC
Message-ID: <7vr69r8sqk.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080718175040.6117@nanako3.lavabit.com>

Nanako Shiraishi <nanako3@lavabit.com> writes:

Show 15 quoted lines

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