Re: [PATCH 3/8] git-merge-recursive-{ours,theirs}

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 26, 2009, 06:15 UTC
Message-ID: <7vr5rlerqf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7e1f1179fc5fe2f568e2c75f75366fa40d7bbbfb.1259201377.git.apenwarr@gmail.com>

"Avery Pennarun" <apenwarr@gmail.com> writes:

Show 7 quoted lines

> This uses the low-level mechanism for "ours" and "theirs" autoresolution
> introduced by the previous commit to introduce two additional merge
> strategies, merge-recursive-ours and merge-recursive-theirs.
>
> (Patch originally by Junio Hamano <gitster@pobox.com>.)
>
> Signed-off-by: Avery Pennarun <apenwarr@gmail.com>

Two comments.

 - The original series was done over a few weeks in 'pu' and this
   intermediate step was done before a better alternative of not using
   these two extra merge strategies were discovered ("...may have been an
   easy way to experiment, but we should bite the bullet", in the next
   patch).

   As the second round to seriously polish the series for inclusion, it
   would make much more sense to squash this with the next patch to erase
   this failed approach that has already been shown as clearly inferiour.

 - I think we should avoid adding the extra argument to ll_merge_fn() by
   combining virtual_ancestor and favor into one "flags" parameter.  If
   you do so, we do not have to change the callsites again next time we
   need to add new optional features that needs only a few bits.

   I vaguely recall that I did the counterpart of this patch that way
   exactly for the above reason, but it is more than a year ago, so maybe
   I didn't do it that way.