Re: [PATCH v3] doc-diff: don't `cd_to_toplevel`
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 6, 2019, 17:24 UTC
- Message-ID
- <xmqqsgx0rfrq.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <nycvar.QRO.7.76.6.1902061303570.41@tvgsbejvaqbjf.bet>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 9 quoted lines
>> For a topic like doc-diff that is primarily meant for developers and >> documenters, it does not matter much, but for an old but important bug, >> forking the topic to fix it at a point close to the origin is >> crucial---that is what would allow people to merge the fix to an older >> maintenance track, without cherry-picking. It is especially true when >> the bug being fixed is more severe than unrelated breakages that have >> been fixed since then. > > As I said, I understand your reasoning.
When I am following-up to the mailing list, not replying directly and solely to you, I may write things that I know you already know to help others reading from sidelines. Just saying I agree, without sounding as if saying "you do not have to say that", would be better.
Show 9 quoted lines
>> - Perhaps find the fork point, run tests to find known breakages >> and exclude them? This would simply be not practical, as it >> doubles the number of tests run, for individual topic branches >> because there are an order of magnitude more of them than the >> primary integration branches. > > I saw another strategy in action: accept the base commit chosen by the > contributor, and ask to back-port it to previous, still supported versions > (unless an automated rebase managed to back-port already).
It sounds more like "notice the base commit chosen by the contributor, reject the series and ask to rebase on a fork point of my choice". That's not all that different from "notice the base commit chosen by the contributor, rebase on a more sensible fork point myself, and double-check the result by merging it to the base commit chosen by the contributor and make sure there is no unmanageable conflict".