On Mon, Dec 27, 2021 at 3:16 PM Elijah Newren <newren@xxxxxxxxx> wrote: > On Sun, Dec 26, 2021 at 11:34 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/ [2]: https://lore.kernel.org/git/CABPp-BHuO3B366uJuODMQo-y449p8cAMVn0g2MTcO5di3Xa7Zg@xxxxxxxxxxxxxx/ > > 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?
