Re: [PATCH 03/13] init: unconditionally create the "info" directory

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 21, 2021, 01:15 UTC
Message-ID: <211221.861r26u4b9.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqq1r27xfi4.fsf@gitster.g>

On Mon, Dec 20 2021, Junio C Hamano wrote:

Show 25 quoted lines

> Derrick Stolee <stolee@gmail.com> 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.