Jonathan Tan <[email protected]> writes:
[jc: pinging the current area expert for the multiple worktree setup
for sanity checking]
> When "git branch -D <name>" is run, Git usually first checks if that
> branch is currently checked out. But this check is not performed if the
> Git directory of that repository is not at "<repo>/.git", which is the
> case if that repository is a submodule that has its Git directory stored
> as "super/.git/modules/<repo>", for example.
>
> This is because get_main_worktree() in worktree.c sets is_bare on a
> worktree only using the heuristic that a repo is bare if the worktree's
> path ends in "/.git", and not bare otherwise. This is_bare code was
> introduced in 92718b7438 ("worktree: add details to the worktree
> struct", 2015-10-08), following a pre-core.bare heuristic. This patch
> does 2 things:
>
> - Teach get_main_worktree() to use is_bare_repository() instead,
> introduced in 7d1864ce67 ("Introduce is_bare_repository() and
> core.bare configuration variable", 2007-01-07) and updated in
> e90fdc39b6 ("Clean up work-tree handling", 2007-08-01). This solves
> the "git branch -D <name>" problem described above. However...
>
> - If a repository has core.bare=1 but the "git" command is being run
> from one of its added worktrees, is_bare_repository() returns false
> (which is fine, since there is a worktree available). However,
> commands like "git worktree list" currently distinguish between a
> repository that has core.bare=1 but has a worktree available, and a
> repository that is truly non-bare (core.bare=0). To preserve this
> distinction, also check core.bare when setting is_bare. If
> core.bare=1, trust it, and otherwise, use is_bare_repository().
I am not sure if the latter is worth keeping, but the former
definitely is a huge improvement, I would imagine. Somebody
did "git branch -D <that-branch>" by accident in a submodule
checkout, or something?
> +test_expect_success 'deleting checked-out branch from repo that is a
> submodule' '
> + test_when_finished "rm -rf repo1 repo2" &&
> +
> + git init repo1 &&
> + git init repo1/sub &&
> + test_commit -C repo1/sub x &&
> + git -C repo1 submodule add ./sub &&
> + git -C repo1 commit -m "adding sub" &&
> +
> + git clone --recurse-submodules repo1 repo2 &&
> + git -C repo2/sub checkout -b work &&
> + test_must_fail git -C repo2/sub branch -D work
> +'
That is a quite straightforward reproduction recipe. Very good.
> diff --git a/worktree.c b/worktree.c
> index b45bfeb9d3..5d52b2ba53 100644
> --- a/worktree.c
> +++ b/worktree.c
> @@ -49,18 +49,17 @@ static struct worktree *get_main_worktree(void)
> struct worktree *worktree = NULL;
> struct strbuf path = STRBUF_INIT;
> struct strbuf worktree_path = STRBUF_INIT;
> - int is_bare = 0;
>
> strbuf_add_absolute_path(&worktree_path, get_git_common_dir());
> - is_bare = !strbuf_strip_suffix(&worktree_path, "/.git");
> - if (is_bare)
> + if (!strbuf_strip_suffix(&worktree_path, "/.git"))
> strbuf_strip_suffix(&worktree_path, "/.");
So, we'd drop /.git or /. from the end, without any behaviour
change. But we no longer take the fact that it was not the ".git"
subdirectory into account, as that is unreliable?
> strbuf_addf(&path, "%s/HEAD", get_git_common_dir());
>
> worktree = xcalloc(1, sizeof(*worktree));
> worktree->path = strbuf_detach(&worktree_path, NULL);
> - worktree->is_bare = is_bare;
> + worktree->is_bare = (is_bare_repository_cfg == 1) ||
> + is_bare_repository();
And instead core.bare being '1' is used as the definite sign
that we are dealing with a bare repository.
It all makes sense to me.
Thanks for working on it.
> add_head_info(worktree);
>
> strbuf_release(&path);
