* [PATCH git] t5516: test updateInstead with worktree and unborn bare HEAD
@ 2026-02-23 14:12 Runxi Yu
2026-02-23 19:15 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Runxi Yu @ 2026-02-23 14:12 UTC (permalink / raw)
To: git; +Cc: Runxi Yu
This is a regression test which should presently fail, to demonstrate
the behavior I encountered that looks like a bug.
When a bare repository has a worktree checked out on a separate branch,
receive.denyCurrentBranch=updateInstead should allow a push to that
branch and update the linked worktree, as long as the linked worktree is
clean.
But, if the bare repository's own HEAD is repointed to an unborn branch,
the push is rejected with "Working directory has staged changes", even
though the linked worktree itself is clean.
This test is essentially a minimal working example of what I encountered
while actually using Git; it might not be the optimal way to demonstrate
the underlying bug. I suspect builtin/receive-pack.c is using the bare
repository's HEAD even when comparing it to the worktree's index.
Signed-off-by: Runxi Yu <me@runxiyu.org>
---
t/t5516-fetch-push.sh | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 29e2f17608..f44250c38f 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1816,6 +1816,24 @@ test_expect_success 'denyCurrentBranch and bare repository worktrees' '
test_must_fail git push --delete bare.git wt
'
+# NEEDSWORK: updateInstead unexpectedly fails when bare HEAD points to unborn
+# branch (or probably any ref that differs from the target worktree) despite
+# the target worktree being clean. This seems to be because receive-pack.c
+# diffs the target worktree index against the bare repository HEAD.
+test_expect_failure 'updateInstead with bare repository worktree and unborn bare HEAD' '
+ test_when_finished "rm -fr bare.git cloned" &&
+ git clone --bare . bare.git &&
+ git -C bare.git worktree add wt &&
+ git -C bare.git config receive.denyCurrentBranch updateInstead &&
+ git -C bare.git symbolic-ref HEAD refs/heads/unborn &&
+ test_must_fail git -C bare.git rev-parse -q --verify HEAD^{commit} &&
+ git clone . cloned &&
+ test_commit -C cloned mozzarella &&
+ git -C cloned push ../bare.git HEAD:wt &&
+ test_path_exists bare.git/wt/mozzarella.t &&
+ test "$(git -C cloned rev-parse HEAD)" = "$(git -C bare.git/wt rev-parse HEAD)"
+'
+
test_expect_success 'refuse fetch to current branch of worktree' '
test_when_finished "git worktree remove --force wt && git branch -D wt" &&
git worktree add wt &&
--
2.53.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH git] t5516: test updateInstead with worktree and unborn bare HEAD
2026-02-23 14:12 [PATCH git] t5516: test updateInstead with worktree and unborn bare HEAD Runxi Yu
@ 2026-02-23 19:15 ` Junio C Hamano
2026-02-24 4:33 ` Runxi Yu
0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2026-02-23 19:15 UTC (permalink / raw)
To: Runxi Yu; +Cc: git
Runxi Yu <me@runxiyu.org> writes:
> This is a regression test which should presently fail, to demonstrate
> the behavior I encountered that looks like a bug.
Did it ever worked before? When did it regress?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH git] t5516: test updateInstead with worktree and unborn bare HEAD
2026-02-23 19:15 ` Junio C Hamano
@ 2026-02-24 4:33 ` Runxi Yu
2026-03-03 10:03 ` Runxi Yu
0 siblings, 1 reply; 4+ messages in thread
From: Runxi Yu @ 2026-02-24 4:33 UTC (permalink / raw)
To: Junio C Hamano, Runxi Yu; +Cc: git
On Tue Feb 24, 2026 at 3:15 AM CST, Junio C Hamano wrote:
> Did it ever worked before? When did it regress?
Not that I know of. Unfortunately it's a bit difficult to build older
versions, but the same logic was present in this commit and in main:
> commit 9fdf4f1db422cc259e4a3ce0023a255102c6fa3b
> Author: Anders Kaseorg <andersk@MIT.EDU>
> Date: Wed Dec 1 14:15:46 2021 -0800
>
> receive-pack: protect current branch for bare repository worktree
>
> A bare repository won’t have a working tree at "..", but it may still
> have separate working trees created with git worktree. We should protect
> the current branch of such working trees from being updated or deleted,
> according to receive.denyCurrentBranch.
>
> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
update finds the destination linked worktree correctly
update_worktree sets GIT_DIR
push_to_deploy decides whether to diff against HEAD or the empty tree by calling head_has_history
but head_has_history uses the bare repo's HEAD rather than the destination worktree
head_has_history used get_oid before vs repo_get_oid now, but they still
both seem to use the bare repo instead of the worktree's HEAD.
So if the bare repo's own HEAD is unborn, in both current main and
9fdf4f1db42, we would be incorrectly choosing the empty tree for the
'has staged changes' check's base, and report failure, even though the
linked worktree is clean
Well, by regression test, I don't mean that this was a previous
regression; I just mean that, this was a way to reproduce this bug that
sounds reasonable and could serve as a future regression test.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH git] t5516: test updateInstead with worktree and unborn bare HEAD
2026-02-24 4:33 ` Runxi Yu
@ 2026-03-03 10:03 ` Runxi Yu
0 siblings, 0 replies; 4+ messages in thread
From: Runxi Yu @ 2026-03-03 10:03 UTC (permalink / raw)
To: Runxi Yu, Junio C Hamano; +Cc: git
I'd appreciate considering this thread again since it's been a bit more
than a week.
Thank you!!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-03-03 10:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-23 14:12 [PATCH git] t5516: test updateInstead with worktree and unborn bare HEAD Runxi Yu
2026-02-23 19:15 ` Junio C Hamano
2026-02-24 4:33 ` Runxi Yu
2026-03-03 10:03 ` Runxi Yu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox