Thread (18 messages) flat view 18 messages, 4 authors, 2021-12-20

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

From: Eric Sunshine <hidden>
Date: 2021-12-20 21:58:28

On Mon, Dec 20, 2021 at 12:29 PM Derrick Stolee [off-list ref] wrote:
On 12/20/2021 10:58 AM, Eric Sunshine wrote:
quoted
`On Mon, Dec 20, 2021 at 9:11 AM Derrick Stolee [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help