Re: [PATCH v3 6/6] worktree: copy sparse-checkout patterns and config on add

On 12/29/2021 2:51 PM, Elijah Newren wrote:

On Wed, Dec 29, 2021 at 9:31 AM Derrick Stolee [off-list ref] wrote:

quoted

On 12/29/2021 1:37 AM, Eric Sunshine wrote:

quoted

On Tue, Dec 28, 2021 at 4:32 PM Derrick Stolee via GitGitGadget
[off-list ref] wrote:

quoted

quoted

The obvious way to work around this problem is to (again) special-case
`core.bare` and `core.worktree` to remove them when copying the
worktree-specific configuration. Whether or not that is the best
solution or even desirable is a different question. (I haven't thought
it through enough to have an opinion.)

It makes sense to special case these two settings since we want to
allow creating a working worktree from a bare repo, even if it has
worktree config stating that it is bare.

Agreed.

quoted

As far as the implementation goes, we could do the copy and then
unset those two values in the new file. That's an easy enough change.

quoted

I'll wait for more feedback on the overall ideas (and names of things
like the init-worktree-config subcommand).

What value does the init-worktree-config subcommand provide; why
shouldn't we just get rid of it?

I know Eric was strongly suggesting it, but he was thinking in terms
of always doing that full switchover step, or never doing it.  Both
extremes had the potential to cause user-visible bugs, and thus he
suggested providing a command to allow users to pick their poison.  I
provided a suggestion avoiding both extremes that doesn't have that
pick-your-poison approach, so I don't see why forcing users into this
extra step makes any sense.

But perhaps I missed something.  Is there a usecase for users to
explicitly use this?

I think the motivation is that worktree config is something that is
harder to set up than to just run a 'git config' command, and we
should guide users into a best practice for using it. The
documentation becomes "run this command to enable it".

It also provides a place to update the steps if we were to change
something in the future around worktree config, but I'm guessing
the ship has sailed and backwards compatibility will keep us from
introducing a new setting that would need to be added here.

Thanks,
-Stolee