Re: [PATCH v3] doc-diff: don't `cd_to_toplevel`
- Date: Wed, 06 Feb 2019 09:24:57 -0800
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH v3] doc-diff: don't `cd_to_toplevel`
Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> 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.
>> - 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