Re: Bug report - Can create worktrees from bare repo / such worktrees can fool is_bare_repository()

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Dec 20, 2021, 21:58 UTC
Message-ID: <CAPig+cTzshfTeNDEbGTaCvZCAjnH-mmzi0i67Wu169wXG2XN2w@mail.gmail.com>
In-Reply-To: <0f98d3e5-f2c2-526a-0476-a89778e5b2b5@gmail.com>

On Mon, Dec 20, 2021 at 12:29 PM Derrick Stolee <stolee@gmail.com> wrote:

Show 18 quoted lines

> On 12/20/2021 10:58 AM, Eric Sunshine wrote:
> > `On Mon, Dec 20, 2021 at 9:11 AM Derrick Stolee <stolee@gmail.com> wrote:
> >> So, we are manually specifying "put this in the config.worktree file"
> >> and not going through some "initialize worktree config" helper. Such
> >> a helper would be useful to avoid this issue in the future.
> >
> > Yes, I was planning to suggest this in a follow-up message.
> > Specifically, I think top-level worktree.[hc] (not builtin/worktree.c)
> > should publish a function which enables worktree-specific
> > configuration _and_ does all the necessary bookkeeping, such as moving
> > `core.bare` and `core.worktree` from .git/config to
> > .git/worktree.config. That way, not only can git-sparse-checkout take
> > advantage of it, but so can any command which needs the functionality
> > in the future, as well as the fictitious "git worktree manage" command
> > I mentioned earlier if it ever materializes.
>
> Ah. I put my change in config.[hc], but let's discuss that in the
> patch series [1].

My concern and sole reason for bringing it up is that this new function (which should be generally useful) should not end up in builtin/sparse-checkout.c. I had suggested worktree.c because its functionality is closely related to worktrees, however, since config.c has intimate knowledge of the location of worktree configuration, that also is a reasonable home for the new function. Either location should be fine; I don't feel strongly either way and don't think it needs a lot (or any) discussion.