On Mon, Nov 30, 2009 at 1:21 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html