Re: [PATCH v2 28/27] tests: run tests omitted by PREPARE_FOR_MAIN_BRANCH

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