Re: Unexpected or wrong ff, no-ff and ff-only behaviour

[Junio C Hamano <gitster@pobox.com>]

Sergey Organov <sorganov@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sergey Organov <sorganov@gmail.com> writes:
>>
>> But the point is, if M and N are equally well tested before
>> publication, they may still have bugs resulting from subtle
>> interactions between A and F..X that is not discovered during that
>> testing.  And N loses the information that would help diagnosing
>> what went wrong, which does not happen if you published M.
>
> I see your point.
>
> My point is that it's still a /choice/ between more information and
> history simplification.

I actually fail to see that point.

If we are not constrained by that "first merge of a topic must be a
redundant fast-forward merge", a topic that originally had two
commits A and B, merged to the mainline to produce M and then
further corrected with a commit C before it gets merged back at O to
the mainline would leave this history:

          A-----------B-------C
         /             \       \
    o---F---o---o---X---M---o---O---

If you enforce the "first merge of a topic must be a redundant
fast-forward merge" rule, you'd end up with a history like this:

          A-----------B
         /
    o---F---o---o---X-------N---o---P---
                     \     /       /
                      A'--B'------C

Is the latter materially simpler than the former?  I do not think
so.

I was preparing myself to say "we rejected the combination because
it would encourage wrong workflow, but perhaps over the years people
like you and usbuser may have found good use patterns different from
what we considered back then, and these use patterns may not
encourage wrong workflows.  It may not be a bad idea to introduce a
new optional behaviour if that is the case", but what I heard so far
does not convince me that we have good use patterns.
>> About the docs easily getting misinterpreted, I think Elijah covered
>> it pretty well.
>
> Yeah, sure, the docs should better be fixed.
>
> Anyway, bare "git --no-ff" is still there, and I can live with no safety
> belt that '--ff-only' could easily have been, it's just that it's a pity
> to see lost opportunities in the design.

Lost opportunities to add an option to encourage bad workflow?  

No, thanks ;-)

But thanks for a discussion anyway.