On 12/30/2021 2:40 AM, Eric Sunshine wrote:
> On Wed, Dec 29, 2021 at 4:40 AM Elijah Newren <newren@xxxxxxxxx> wrote:>
Taking time to focus only on this outline here:
>> So, I'd like to reiterate my earlier suggestion which would avoid
>> these regressions while also fixing the reported bug:
>> * If core.bare=true or core.worktree is set, then at `git worktree
>> add` time, automatically run the logic you have here for
>> init-worktree-config. Having either of those config settings with
>> multiple worktrees is currently broken in all git versions and likely
>> in most all external tools. As such, being aggressive in the new
>> config settings to allow new versions of git to work seems totally
>> safe to me -- we can't be any more broken than we already were.
I'm not sure I agree with the "currently broken in all git versions"
because when extensions.worktreeConfig is not enabled, the core.bare
and core.worktree settings are ignored by the worktrees. This upgrade
during 'add' is the only thing I am not so sure about.
>> * If core.bare=false and core.worktree is not set, then:
>> * `git sparse-checkout {init,set}` should set
>> extensions.worktreeConfig if not already set, and always set the
>> core.sparse* and index.sparse settings in worktree-specific files.
This should happen no matter the case of core.bare and core.worktree
existing, right?
>> * `git worktree add`, if extensions.worktreeConfig is already set,
>> will copy both the info/sparse-checkout file and the config.worktree
>> settings (module core.bare and core.worktree, if present) to the new
>> worktree
and here, 'git worktree add' should always copy the info/sparse-checkout
file (if core.sparseCheckout is enabled) and copy the config.worktree
settings if extensions.worktreeConfig is enabled (and filter out
core.bare and core.worktree in the process).
> Thanks for the clearly written enumeration of how you expect this to
> work. This summary pretty well (or entirely) captures the conclusions
> I arrived at, as well, after devoting a chunk of time today thinking
> through the cases. If I'm understanding everything correctly, the
> approach outlined here solves the bare-worktree problem in the least
> invasive and least dangerous way (for older Git versions and foreign
> tools). And we don't even need the `git worktree init-worktree-config`
> subcommand (though we need the underlying functionality).
I'm happy to drop the subcommand in favor of some documentation in
git-config.txt (Documentation/config/extensions.txt to be exact).
Thanks,
-Stolee
