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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 15, 2019, 16:57 UTC
Message-ID: <xmqqtvbn44mx.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <874l3nzcpo.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 14 quoted lines

> 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.

Show 8 quoted lines

>> 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.