Re: [RFC/PATCH Second draft] Fast forward strategies allow, never, and only

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 22, 2008, 19:49 UTC
Message-ID: <7vbq56ilnj.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <402c10cd0803192347q7b4a3fb0s35737f361d53a86a@mail.gmail.com>

"Sverre Hvammen Johansen" <hvammen@gmail.com> writes:

Show 16 quoted lines

> On Wed, Mar 19, 2008 at 12:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> > ...
>>  This might be easier to review if split into two parts.  Code suffling to
>>  do --ff/--no-ff => ff={allow,never} and documentation updates to improve
>>  the description of these two options in the first patch, and addition of
>>  "only" to code and the updated docuemntation in the second.
>
> What I would like to do is to split it in three like this:
>
> 1. Head reduction
>
> 2. --ff/--no-ff => ff={allow,never} and documentation updates.
>
> 3. --ff=only
>
> If you would like me to do this please tell me.

Yeah, making head reduction into its own separate patch would make things clearer, I guess.

But if you are going to do that, then the order should be 2/1/3 from the above list. In a series of patches, restructuring without changing semantics should come first to make existing logic cleaner and later enhancements on top of it easier to follow. Then you build new features and enhancements on top of that solidified base.

Because "head reduction" changes the semantics (making it better or worse does not matter --- "changes" is what matters), it should come after #2 above, I think.