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 [off-list ref] wrote:

On Sun, Dec 26, 2021 at 11:34 PM Eric Sunshine [off-list ref] wrote:

quoted

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/ (local)
[2]: https://lore.kernel.org/git/CABPp-BHuO3B366uJuODMQo-y449p8cAMVn0g2MTcO5di3Xa7Zg@mail.gmail.com/ (local)

quoted

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?