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

Johannes Schindelin [off-list ref] writes:

quoted

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.

quoted

 - 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".