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

Sergey Organov [off-list ref] writes:

quoted

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.

About the docs easily getting misinterpreted, I think Elijah covered
it pretty well.

Thanks.