On 12/20/2021 11:13 AM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Dec 20 2021, Derrick Stolee wrote: > >> On 12/12/2021 3:13 PM, Ævar Arnfjörð Bjarmason wrote: >>> 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? > > 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
