From e01de1c9122c3cba118da19fe0ba0ce913fa7285 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 15 Mar 2010 22:12:55 -0700 Subject: refs: ref entry with NULL sha1 is can be a dangling symref Brandon Casey noticed that t5505 had accidentally broken its && chain, hiding inconsistency between the code that writes the warning to the standard output and the test that expects to see the warning on the standard error, which was introduced by f8948e2 (remote prune: warn dangling symrefs, 2009-02-08). It turns out that the issue is deeper than that. After f8948e2, a symref that is dangling is marked with a NULL sha1, and the idea of using NULL sha1 to mean a deleted ref was scrapped, but somehow a follow-up eafb452 (do_one_ref(): null_sha1 check is not about broken ref, 2009-07-22) incorrectly reorganized do_one_ref(), still thinking NULL sha1 is never used in the code. Fix this by: - adopt Brandon's fix to t5505 test; - introduce REF_BROKEN flag to mark a ref that fails to resolve (dangling symref); - move the check for broken ref back inside the "if we are skipping dangling refs" code block. Signed-off-by: Junio C Hamano --- t/t5505-remote.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 't/t5505-remote.sh') diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index e70246b3fb..98e8ec03d3 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -478,15 +478,15 @@ test_expect_success 'remote prune to cause a dangling symref' ' ( cd seven && git remote prune origin - ) 2>err && + ) >err 2>&1 && grep "has become dangling" err && - : And the dangling symref will not cause other annoying errors + : And the dangling symref will not cause other annoying errors && ( cd seven && git branch -a ) 2>err && - ! grep "points nowhere" err + ! grep "points nowhere" err && ( cd seven && test_must_fail git branch nomore origin -- cgit v1.2.3