Ævar Arnfjörð Bjarmason [off-list ref] writes:
I don't see why we'd consider that as a worthwhile direction to go
in. The "git-init" documentation states:
This command creates an empty Git repository - basically a `.git`
directory with subdirectories for `objects`, `refs/heads`,
`refs/tags`, and template files.
I.e. we promise to create "objects", but not "objects/{info,pack}", even
though we've done so since f49fb35d0d5 (git-init-db: create "pack"
subdirectory under objects, 2005-06-27) and d57306c7945 (Create
objects/info/ directory in init-db., 2005-08-20).
I view it as a documentation bug, though.
The only thing we need to promise is that (1) the directory prepared
by "git init" will be recognised as a repository by the current and
future versions of Git (and hopefully the existing ones, too), and
(2) versions of Git will not barf due to missing directory and stuff
due to end-user mischief around custom templates. I do not think we
even need refs/heads/ directory and I do not see that, especially
with a presence with "basically" there, the sentence promises that
we will always create refs/tags/ directory. For (1), only objects/,
refs/ and HEAD is necessary, as long as (2) is satisfied by lazy
creation of leading paths.
We would want to be able to cope with a repository that lost
.git/info directory due to loss of it in custom templates anyway.
Just like we create leading missing directories lazily for any
hierarchy under .git/, we should create .git/info on-demand.
Pre-creating .git/info might be nice, but becomes much less
important after it happens, and that is why I view it as a much
lower priority than what Derrick suggested.
On Mon, Dec 20 2021, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
I don't see why we'd consider that as a worthwhile direction to go
in. The "git-init" documentation states:
This command creates an empty Git repository - basically a `.git`
directory with subdirectories for `objects`, `refs/heads`,
`refs/tags`, and template files.
I.e. we promise to create "objects", but not "objects/{info,pack}", even
though we've done so since f49fb35d0d5 (git-init-db: create "pack"
subdirectory under objects, 2005-06-27) and d57306c7945 (Create
objects/info/ directory in init-db., 2005-08-20).
I view it as a documentation bug, though.
The only thing we need to promise is that (1) the directory prepared
by "git init" will be recognised as a repository by the current and
future versions of Git (and hopefully the existing ones, too), and
(2) versions of Git will not barf due to missing directory and stuff
due to end-user mischief around custom templates. I do not think we
even need refs/heads/ directory and I do not see that, especially
with a presence with "basically" there, the sentence promises that
we will always create refs/tags/ directory. For (1), only objects/,
refs/ and HEAD is necessary, as long as (2) is satisfied by lazy
creation of leading paths.
Do you think that we should stop creating objects/{pack,info} then,
provided that the few test failures that assume them are cleand up
(which for at least one of them is much easier than the top-level
"info")?
We would want to be able to cope with a repository that lost
.git/info directory due to loss of it in custom templates anyway.
Just like we create leading missing directories lazily for any
hierarchy under .git/, we should create .git/info on-demand.
Pre-creating .git/info might be nice, but becomes much less
important after it happens, and that is why I view it as a much
lower priority than what Derrick suggested.
Yes, we agree that we should deal with it not being created, that we
don't is a bug in sparse-checkout.
That's still a separate question from whether it's worthwhile investment
of both our and user time to skip creating them and deal with the
resulting churn in the tests and needlessly break code in the wild.
It seems as though you're saying that any fixes or changes in this area
would be incomplete without moving us towards the most pedantic and
minimalist interpretation possible when doing a "git init", is that
right?
I.e. to end up with this .git from "git init --template=" (the same as
now plus rmdir .git/{objects,refs}/*):
$ tree -a -p
.
└── [drwxr-xr-x] .git
├── [-rw-r--r--] config
├── [-rw-r--r--] HEAD
├── [drwxr-xr-x] objects
└── [drwxr-xr-x] refs
3 directories, 2 files
I can work towards that with these patches, it just seems to me to be
needlessly creating potential issues for little or no benefit.