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

On 12/20/2021 11:13 AM, Ævar Arnfjörð Bjarmason wrote:

On Mon, Dec 20 2021, Derrick Stolee wrote:

quoted

On 12/12/2021 3:13 PM, Ævar Arnfjörð Bjarmason wrote:

quoted

But we've also grown a hard dependency on this directory within git
itself. Since 94c0956b609 (sparse-checkout: create builtin with 'list'
subcommand, 2019-11-21) released with v2.25.0 the "git
sparse-checkout" command has wanted to add exclusions to
"info/sparse-checkout". It didn't check or create the leading
directory, so if it's omitted the command will die.

quoted

Even if that behavior were fixed we'd be left with older versions of
"git" dying if that was attempted if they used a repository
initialized without a template.

This, I don't understand. Why can't we add a
safe_create_leading_directories() to any place where we try to
create a sparse-checkout file?

This would fix situations where older versions were init'd with a
different template or if the user deleted the info dir. The change
you've made here doesn't fix those cases, which is what you are
claiming is the reason to not do the other fix that seems like it
would.

What am I misunderstanding here?

I'll clarify that a bit in any re-roll.

Pedantically nothing changes, i.e. you can create a repository with an
empty template now, and it'll break on both the sparse-checkout on that
version, and any previous version that had that un-noticed issue.

You continue after this with more motivations for adding 'init' 
unconditionally, which I am not fighting.

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.

Thanks,
-Stolee