I see that Rene Scharfe has also worked on the same issue, while I was
preparing these patches...
On Mon, Oct 15, 2012 at 11:29 AM, Junio C Hamano <jch2...@gmail.com> wrote:
> Even though update-ref deferences a symref when it updates one to point at a
> new object, I personally don't think update-ref -d that derefs makes any
> sense. I'd rather see it error out when given a symref, with or without
> --no-deref option.
I'm not sure. We have multiple testcases that directly test deleting a ref
through a symref (e.g. t1400), so supporting this seems like a concious
decision. Erroring out when given a symref will break the following
- t1400 (git update-ref -d)
- t3310 & t3311 (git notes merge --abort is broken)
- t5505 (git remote set-head --delete and renaming a remote is broken)
> But even if it did, removing a ref pointed by a symref should really remove
> it, and forgetting to remove a leftover entry in packed-ref has no excuse
> I'd say what you observed is a double bug.
Patch #1 - #2 fixes the 2nd bug (removing through a symref should remove
both loose and packed versions of the ref).
Patch #3 fixes an associated problem where deleting a symref would remove
the dereferenced ref's reflog instead of the symref's reflog.
Patch #4 - #5 introduces solution A presented in my previous mail (i.e.
'git branch -d' never dereferences symrefs).
Johan Herland (5):
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
delete_ref(): Fix deletion of refs through symbolic refs
delete_ref(): Remove the correct reflog when deleting symrefs
Add tests for using symbolic refs as branch name aliases.
branch -d: Fix failure to remove branch aliases (symrefs)
builtin/branch.c | 2 +-
refs.c | 35 +++++++++++-----------
t/t1400-update-ref.sh | 18 +++++++++++
t/t3220-symbolic-ref-as-branch-alias.sh | 53 +++++++++++++++++++++++++++++++++
4 files changed, 90 insertions(+), 18 deletions(-)
create mode 100755 t/t3220-symbolic-ref-as-branch-alias.sh
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html