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. About the docs easily getting misinterpreted, I think Elijah covered it pretty well. Thanks.
