Hi Junio, On Thu, 19 Nov 2020, Junio C Hamano wrote: > 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? Well, I was naive enough to think that this whole "let's transition the test suite to use `main` as default branch name" business would go over much quicker. With that expectation, I was content to already have `PREPARE_FOR_MAIN`-marked test cases in t5526 and t9902. They are currently skipped because that prereq is still waiting for the transition to complete. That's what my promise was about: as soon as the competing topics settle, I want to address those two test scripts in particular, moving them over to `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main`. > 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. FWIW I think you do a wonderful job of keeping the patch series in `seen`. I wish we could keep the CI build passing a bit more, but I'd rather have the branches that are in flight in one place, so that it is easy e.g. to find out whether `git diff next..seen -- t/t9902\*` is empty (to determine whether working on that script would cause conflicts right now). Ciao, Dscho
