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

From: Sergey Organov <sorganov@gmail.com>
Date: Jul 19, 2019, 11:00 UTC
Message-ID: <87r26me1bb.fsf@osv.gnss.ru>
In-Reply-To: <xmqqtvbn44mx.fsf@gitster-ct.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

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

I'm sorry you do. Let me try again.

Show 22 quoted lines

>
> 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 think it is. To see it clearly, let's cut common parts, and then cut irrelevant parts as well from the pictures you gave:

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

                  ---X-------N---
                      \     /
                       A'--B'

There is both qualitative and quantitative difference here.

1. The qualitative difference.

In the former case we have outdated topic branch and a merge commit that simultaneously serves two purposes: gives a recipe to bring outdated branch up to date, and records the fact that the topic in now merged to mainline.

In the letter case we have up to date topic branch and a merge commit that servers exactly one one purpose: it records the fact that the topic in now merged to mainline.

This is exactly the "material" part of the simplification I mean.

2. The quantitative difference.

In the latter case the horizon to reason about the topic branch and its adoption to mainline is at commit X, while in the former case it is at commit F.

The quantitative difference that we have here is proportional to the size of diff between X and F, and once we aim at decreasing this difference (i.e., not accepting very outdated branches), it's only logical to get rid of this difference entirely, once again ending up with the latter case.

Finally, please also notice that ability to reference outdated version of the topic branch (or even multiple of them), provided there is actual reason to, is still there:

$ git checkout topic $ git pull --rebase $ git merge -s ours topic@{1} # keep reference to original $ git checkout mainline $ git merge --no-ff topic

Show 20 quoted lines

> 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 ;-)

I dunno what is that "bad workflow" you have in mind, sorry.

-- Sergey