On Thu, Dec 30, 2021 at 1:38 PM Elijah Newren <newren@xxxxxxxxx> wrote:
> On Wed, Dec 29, 2021 at 10:41 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> > On Tue, Dec 28, 2021 at 1:16 PM Elijah Newren <newren@xxxxxxxxx> wrote:
> > > On Mon, Dec 27, 2021 at 11:33 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> > > > 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).
