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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Thu, 19 Nov 2020, Junio C Hamano wrote:

> 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?

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