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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/12/2021 3:13 PM, Ævar Arnfjörð Bjarmason wrote:
> In preceding commits the test suite has been taught to run without a
> template directory, but in doing so we needed to fix code that relied
> on the "hooks" and "branches" directories.
> 
> The "hooks" code was all specific to our own test suite. The
> "branches" directory is intentionally created, but has been "slightly
> deprecated" for a while, so it's not created when not using the
> default template.
> 
> However "info" is different. Trying to omit its creation would lead to
> a lot of test suite failures. Many of these we should arguably fix,
> the common pattern being to add an exclude to "info/excludes".

This would be painful to add because of the impact on the test suite.
That I understand.
 
> 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.

> 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?

> So let's just bite the bullet and make the "info" directory mandatory,
> and document it as such. Let's also note that in the documentation
> that this doesn't apply to the "hooks" and "branches" directories.

I have no objection to this approach, but we should still do the
other thing.

Thanks,
-Stolee



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux