Re: Merging using only fast-forward
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 16, 2008, 22:49 UTC
- Message-ID
- <7v3asxo06n.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <402c10cd0801161438u7443ebf2xdf1d6f3040ceb1a9@mail.gmail.com>
"Sverre Hvammen Johansen" <hvammen@gmail.com> writes:
Show 17 quoted lines
> On Jan 16, 2008 12:31 PM, Junio C Hamano <gitster@pobox.com> wrote: >> A sane integration is a different story. >> >> We have --ff and --no-ff options to merge. How should this new >> option --ff-only mesh with them? Perhaps we would want to have >> an option --ff that takes three values? >> >> --ff=never >> --ff=normal >> --ff=only >> >> and have the first one be synonym for existing --no-ff, the second >> one to be a synonym for not giving anything (or giving --ff >> explicitly), and the third one to be this new mode of operation? > > Thanks for the patch. I can probably look into it tonight and do the > suggested integration and test it out, I keep you posted.
Well, no, I did not _suggest_ that particular integration. I do not even know what the right answer is to these questions. The UI that pastebin patch implements, which uses totally separate flags, may turn out to be the right approach. If you want to carry the torch forward on this topic, that's great. It is very much appreciated. But one of the things included in that work includes thinking and deciding which UI is better between the patch in the pastebin and the one that tries to introduce a unified --ff=<value> option. I simply do not know the answer, and prefer not having to think about it during a pre-release feature freeze.
Coming up with a 7-liner quick-and-dirty solution is one thing. It was easy (although I haven't tested it, so it may not work at all!). But if we want to mainline it, we need to think carefully how the new feature integrates well with what we already have. That's all I wanted to say.