Re: Unexpected or wrong ff, no-ff and ff-only behaviour
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 12, 2019, 18:33 UTC
- Message-ID
- <xmqqh87rp0gy.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <87blxz9xbh.fsf@osv.gnss.ru>
Sergey Organov <sorganov@gmail.com> writes:
Show 24 quoted lines
>> 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.