Re: [PATCH 00/17] tests: access bare repositories explicitly

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

Hi Junio,

On Thu, 2 Apr 2026, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > The safe.bareRepository configuration variable (introduced in
> > 8d1a7448206e) allows restricting implicit bare repository discovery.
> > Its default may well change to "explicit" in Git v3.0, at which point
> > any test that relies on implicit discovery of a bare repository would
> > break, even if the test subject has nothing to do with bare
> > repositories.
> 
> I do not recall such a change for safe.bareRepository discussed in
> the recent past, and I do not have a strong opinion yet because of
> that, but if no such change to require "explicit" comes, we would be
> losing test coverage with these patches, because these rewrite the
> ones that rely on a working code in implicit cases?

Note that the commit message says "may well" not "will". Precisely because
such a discussion has not been had in the recent past.

But yes, that discussion has not happened, and I was quite surprised about
that when I recently looked (I prepared some of my code for such a change,
assuming that Git 3.0 as a natural inflection point would be the time for
8d1a7448206e's long journey to come to a conclusion).

> Shoudln't there be a patch [01/18] before everything else that
> updates Documentation/BreakingChanges.adoc to propose the default
> change?

Well, yes and no. There should be an update to BreakingChanges to propose
that default change, but obviously it should not only be a documentation
change: It should also adjust `Documentation/config/safe.adoc` to mention
the intended change of behavior, and it should introduce
`WITH_BREAKING_HANGES`-specific conditional code in `setup.c`.

And, crucially, it should pass the test suite under WITH_BREAKING_CHANGES.

To do that, a lot more needs to happen than just the 17 patches in this
here patch series. Most of the additional changes are quite mechanical,
and can be validated relatively easily despite their sheer number. And
only at the very end of those changes can that `safe.bareRepository`
change even be proposed. The eventual patch that does what you ask (but
not as 1/18, for the reasons I outlined above), and more, is:
https://github.com/gitgitgadget/git/pull/2072/changes/435e3505e7997a25f45777a6ba436899a793c59c

I plan on proposing that patch in due time, to start the discussion
whether or not it is a good idea to change the default of
`safe.bareRepository` in Git 3.0.

Ciao,
Johannes