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

Junio C Hamano [off-list ref] writes:

Sergey Organov [off-list ref] writes:

quoted

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.

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