On Mon, Dec 20 2021, Junio C Hamano wrote:
> Derrick Stolee <stolee@xxxxxxxxx> writes:
>
>> What I _am_ saying is important is that if we are trying to write
>> a file to a known location and its parent directory doesn't exist,
>> then we should create it. Not doing so is a bug and should be
>> fixed, no matter how rare such a thing is to occur. As you've
>> shown, it is not required to have an info directory until we need
>> one (e.g. for sparse-checkout or an excludes file).
>>
>> If you're not planning to add that to this series, then I'll add it
>> to my list. I do think it would fit well into this one, though.
>
> Historically, "git init" relied on the templates to create necessary
> directories, and the subcommands in turn learned to depend on the
> presence of these directories.
>
> At the same time we allowed that the templates can be customized by
> the end users. It was a bug, exactly for the reason you said above.
>
> Before we talk about creating 'info' directory directly in "git
> init" or anything done in this topic, we should fix the existing
> bug, and the right fix is to use safe-create-leading-directories.
>
> With that, it may become unnecessary to have this "create 'info' in
> 'init'".
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).
Our test suite reveals our own assumptions, but it's also indicative of
assumptions others have made.
It's cheap to create .git/info unconditionally, and we create similar
empty subdirectories, so why not do it for .git/info? Why would we
needlessly break widely documented out-of-tree recipies like:
some-user-excludes >.git/info/excludes
Which yes, rely on something you can't strictly rely on, but is true
enough most of the time that people do.
So I don't see what finding and fixing every instance of assuming
.git/info in the test suite buys us.
After doing that we'd be back to square one of having to decide if
exposing a mode that effectively did the same could be overly pedantic
in that case, or cheaply cater to out-of-tree code that made the same
assumption.
That's the question this topic is mainly trying to address. It's also
worthwhile to fix the in-tree dependency in sparse-checkout, but I don't
see why we'd insist that one can't be done without the other.
