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