Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> 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
