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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Nov 30, 2009, 18:08 UTC
Message-ID: <32541b130911301008v4156f0c6ge9f30952565392f9@mail.gmail.com>
In-Reply-To: <7vvdgs1qip.fsf@alter.siamese.dyndns.org>

On Mon, Nov 30, 2009 at 1:21 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> As long as you choose the default "no-op" value carefully enough so that
> existing callers will naturally use it without modification, the old code
> will work the way they did before the new optional feature was added.  In
> other words, "let's implement this as purely an opt-in feature" is often
> preferrable over "let's force semantic conflict and compilation failure,
> just in case existing callsites may also want to trigger this new
> feature".
>
> That is why [1/8] patch in your series uses 0 to mean "don't do the funny
> 'favor' trick, but just leave the conflicts there".

There's just one bit to add to this: when converting a non-bitfield int into a bitfield, really odd things can happen. That was my main rationale for avoiding the change to bitfield without changing the signature. That said, the amount of code isn't really that big so this point doesn't matter much.

> I've queued the series with minor fixes to 'pu' and pushed it out.

Since I see you didn't change a couple of things you mentioned in earlier comments (the NEEDSWORK comment and the sq-then-eval trick) do you still want me to respin this series?

Thanks,

Avery