On 2020-11-20 at 18:39:03, Jeff King wrote:
> t1300 is full of this kind of junk. Several years ago, while working on
> some of the repositoryformatversion code, I noticed that we will accept
> a repository that does not have core.repositoryformatversion set at all,
> nor even has a .git/config present!

Yup.  We test this in t3200 as well.  I don't love it, but it exists.

> It's easy to fix in the code, but it causes failures all over t1300. So
> then I started converting t1300 to use "config --file" (which
> almost certainly didn't exist back when most of those tests were
> originally written).  I don't remember how or why it got hairy, but it
> was enough that I eventually dropped it (unlike many of my other stale
> topics, I don't think I've even kept rebasing it forward as a WIP).
> 
> Possibly I was concerned that people in the wild were relying on a blank
> or missing config being the same as repositoryformatversion=0. That will
> definitely stop working in a sha256 world anyway, though, because
> they'll need the objectFormat extension.

Which is exactly why that test in t3200 has a SHA1 prerequisite.  I'm
sure we'll hear someone complain about the fact that SHA-256
repositories have to have a config file, but I'm fine with us not
supporting it.

I should point out that lacking a config file also only works on Unix
systems with a POSIX file system (including case-sensitive macOS), since
otherwise core.ignorecase (and core.symlinks, if appropriate) aren't set
correctly.  It also doesn't work for bare repositories on any OS.  So
hopefully the number of people doing this is quite small.

> So that got a bit off-track, but I think:
> 
>   - t1300 already is very much like this, so it's not a new thing
> 
>   - but I would be happy not to see it go further in that direction,
>     even if it means inconsistency with the rest of the script

I agree we shouldn't make things worse.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US