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

From: Sergey Organov <[email-masked]>
Date: Mon, 15 Jul 2019 15:47:31 +0300

Junio C Hamano <[email-masked]> writes:

> Sergey Organov <[email-masked]> writes:
>
>>> If we have a project like this:
>>>
>>>         A               topic that is slightly stale
>>>        /
>>>   o---F---o---o---X     mainline
>>>
>>> M, A', and N should end up with identical trees:
>>>
>>>
>>>         A-----------M   topic that is slightly stale, merged into mainline
>>>        /           /
>>>   o---F---o---o---X---N mainline with A' merged
>>>                    \ /
>>>                     A'  mainline with A rebased on top as A'
>>>
>>> And by forcing to rebase A to A' before merging into the mainline as
>>> N, compared to advancing mainline from X to M, one major difference
>>> the workflow is making is to _lose_ the information that the topic
>>> was cooked in the context of an older mainline and did not take what
>>> happened since F until X into account....
>>
>> However, committing untested M still doesn't taste as the best possible
>> way of handling things in general. It'd be best to actually test M or N
>> before publishing.
>
> Oh, no question about it.  I am not advocating (and I do not do
> personally) publishing an untested tip.  
>
> 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. It's not one way. I dispute that keeping
reference to the original branch has enough significance to /always/
overweight opportunity for history simplification, no matter what
workflow is in use.

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

Thanks,

-- Sergey