Re: [PATCH v3] doc-diff: don't `cd_to_toplevel`

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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
unmanageable conflict".