Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > The conflicts might be trivial, but every conflict makes it harder to > juggle branch thickets like Junio's `seen`. And those things add up. > They're no fun, and they make life hard and tedious. The worst part is they can easily be cause of unintended breakage due to mismerge. > t5526 conflicts _semantically_ with `pk/subsub-fetch-fix` (which touches > t5526 and adds a new test case referring to `master`). > > t9902 conflicts with `fc/bash-completion-post-2.29`, and in contrast to > the t5526 issue (which is trivial, even if it does require manual fixing), > the t9902 is a bit more hairy to reason about. > > So yes, I would love to have that test coverage back, but not by making > the transition to `main` even harder by reverting parts of it. Hmph, wouldn't the forcing with GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME to 'master' be the right way to keep test coverage? After all, the primary goal is to prepare tests so that we won't lose coverage when the fallback default of init.defaultbranch is switched to 'main', and it is a secondary goal of much lessor importance to reduce the number of hits from "git grep master t/". > That's why I promised publicly to take care of the loose ends as quickly > as I can, after the conflicting issues graduate to `next` (or when they > become stalled or even dropped from `seen`). Perhaps I should start to more aggressively drop topics from `seen` that are not sufficiently reviewed? The guiding principle ought to be "unreviewed patches are not worth applying", but I have a feeling that we have become more and more lax over time due to shortage of quality reviews. I dunno.
