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

> Sergey Organov <sorganov@gmail.com> 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.