Re: [PATCH v2 0/5] Sparse checkout: fix bug with worktree of bare repo

>
> On Mon, Dec 27, 2021 at 3:16 PM Elijah Newren <newren@gmail.com> wrote:
> > On Sun, Dec 26, 2021 at 11:34 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > > Your proposal is _almost_ the same as my suggestion of eventually
> > > making per-worktree config the default. The difference is that you're
> > > only making it the default if `core.bare=true` or `core.worktree` is
> > > set.
> >
> > Indeed.  :-)
>
> I mentioned previously[1] that I needed to find a block of time to
> really think through the topic before I'd be able to respond to this
> email. So, today I spent some time trying to reason through the
> various cases under discussion, and I came back and re-read this email
> with the intention of trying to summarize my understanding of the
> situation and my understanding of the points you were making. However,
> you did such a good job of summarizing the various cases at the very
> end of [2] that it probably makes more sense for me to respond to that
> email instead.
>
> [1]: https://lore.kernel.org/git/CAPig+cTFSDw-9Aq+=+r4sHSzTmG7s2T93Z0uqWTxHbKwGFaiYQ@mail.gmail.com/
> [2]: https://lore.kernel.org/git/CABPp-BHuO3B366uJuODMQo-y449p8cAMVn0g2MTcO5di3Xa7Zg@mail.gmail.com/
>
> > > But do we need that distinction? If people are comfortable with
> > > that, then are they comfortable with simply flipping the switch and
> > > making per-worktree config the default today regardless of `core.bare`
> > > and `core.worktree`?
> >
> > This is tempting, at least if we leave core.repositoryFormatVersion as
> > 0 (see 11664196ac ("Revert "check_repository_format_gently(): refuse
> > extensions for old repositories"", 2020-07-15)) when core.bare is
> > false and core.worktree was unset.  However, for that case:
>
> I had seen 11664196ac when researching one of my earlier responses,
> though it took more than one read to (hopefully) fully understand what
> it is saying (i.e. due to an oversight, it's too late to enforce the
> `core.repositoryFormatVersion=1` requirement when extensions are used,
> as originally intended).
>
> > * This is a case where operating on the primary worktree was not
> > previously problematic for older git versions or third party tools.
> > * Interestingly, git <= 2.6.2 can continue to operate on the primary
> > worktree (because it didn't know to error out on unknown extensions)
> > * git >= 2.19.0 could continue to operate on the primary worktree
> > (because it understands the extension)
> > * git versions between that range would suddenly break, erroring out
> > on the unknown extension (though those versions would start working
> > again if we migrated core.bare and core.worktree but just didn't set
> > extensions.worktreeConfig).
>
> The significance of versions 2.6.2 and 2.19.0 is unclear to me. What
> context or criteria are you using to identify those versions as
> meaningful here?