refs: ref entry with NULL sha1 is can be a dangling symref
commite01de1c9122c3cba118da19fe0ba0ce913fa7285
authorJunio C Hamano <gitster@pobox.com>
Tue, 16 Mar 2010 05:12:55 +0000 (15 22:12 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 16 Mar 2010 06:37:42 +0000 (15 23:37 -0700)
tree771e254d2c8f33f3bb91512f6f04d68a17078f30
parent011c181cc656c8b3e48882729d1b6238e8c5c537
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 <gitster@pobox.com>
refs.c
t/t5505-remote.sh