On Wed, Dec 29, 2021 at 10:22 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > 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? We had been discussing how certain config settings "might break external tools OR old git versions", but hadn't brought up which tools or which git versions. I don't know which all external tools might be in play (though I mentioned some in use at $DAYJOB in another thread) but in this email I had just thought that I'd mention where the cutoff point was in terms of git versions which understood core.repositoryFormatVersion and extensions.worktreeConfig. If other folks also want to test how things behaved before or after these patches with "old git versions", those were the switchover points that are relevant and which I tested with.
