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

On Thu, Dec 30, 2021 at 1:38 PM Elijah Newren [off-list ref] wrote:

On Wed, Dec 29, 2021 at 10:41 PM Eric Sunshine [off-list ref] wrote:

quoted

On Tue, Dec 28, 2021 at 1:16 PM Elijah Newren [off-list ref] wrote:

quoted

On Mon, Dec 27, 2021 at 11:33 PM Eric Sunshine [off-list ref] wrote:

quoted

A more general approach might be for the new worktree to copy all the
per-worktree configuration from the worktree in which the command was
invoked, thus sparsity would be inherited "for free" along with other
settings. This has the benefits of not requiring sparse-checkout
special-cases in the code and it's easy to document ("the new worktree
inherits/copies configuration settings from the worktree in which `git
worktree add` was invoked") and easy to understand.

Ooh, this is a good point and I *really* like this simple solution.
Thanks for pointing it out.

I do wonder, though, if there are traps waiting for us with this
all-inclusive approach. I don't know what sort of worktree-specific
configuration people use, so I do worry a bit that this could be
casting a too-wide net, and that it might in fact be better to only
copy the sparse-checkout settings (as ugly as it is to special-case
that -- but we need to special-case `core.bare` and `core.worktree`
anyhow[1]).

I could probably be persuaded either way (do users want to copy
something and tweak it, or start with a clean slate?), and it might
even make sense to have a flag for users to specify.

I also could probably be persuaded either way, and yes a flag is a
possibility, though it would be nice if we could get along without it.

My hunch, at least with the developers I work with, is that they're
more likely to think in terms of "I want another worktree like this
one, except that I'm going to change..."

Also, another reason to prefer copying all of core.worktree (minus the
always worktree-specific value of core.worktree, and core.bare), is
because it's easy to explain in the documentation, and I think we'd be
much less likely to obsolete user's knowledge over time.  (I think
additional sparse-checkout things, or new other features that also
want to be copied over, are much more likely than the addition of keys
that are always worktree-specific like core.worktree).

Another possible point in favor of copying all worktree-specific
config to the new worktree is that if the user really does want to do
some configuration specific to the new worktree, then that is going to
require a certain amount of manual setup after creating the new
worktree regardless of whether we copy all worktree-specific config or
only a select subset (such as the sparse-checkout settings).