From: Junio C Hamano <gitster@pobox•com>
To: "René Scharfe" <rene.scharfe@lsrfire•ath.cx>
Cc: Johan Herland <johan@herland•net>,
Git mailing list <git@vger•kernel.org>,
Miklos Vajna <vmiklos@suse•cz>
Subject: Re: BUG when trying to delete symbolic refs
Date: Tue, 16 Oct 2012 09:09:09 -0700 [thread overview]
Message-ID: <7vr4oytn4q.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <507D315E.8040101@lsrfire.ath.cx> ("René Scharfe"'s message of "Tue, 16 Oct 2012 12:05:18 +0200")
René Scharfe <rene.scharfe@lsrfire•ath.cx> writes:
> Am 15.10.2012 10:50, schrieb Johan Herland:
>> Basically, there is a "master" branch, and an "alias" symref to
>> "master". When we naively try to delete the symref with "git branch -d
>> alias", it ends up:
>>
>> - NOT deleting the "alias" symref
>> - DELETING the "master" loose ref
>> - NOT deleting the "master" packed ref
>>
>> So, from the user perspective, "git branch -d alias" ends up resetting
>> "master" (and "alias") back to the last time we happened to run "git
>> gc". Needless to say, this is not quite what we had in mind...
>>
>> AFAICS, there may be three possible "acceptable" outcomes when we run
>> "git branch -d alias" in the above scenario:
>>
>> A. The symbolic ref is deleted. This is obviously what we expected...
>
> Below is a patch to do that.
>
>> B. The command fails because "alias" is a symref. This would be
>> understandable if we don't want to teach "branch -d" about symrefs.
>> But then, the error message should ideally explain which command we
>> should use to remove the symref.
>
> Renaming of symrefs with branch -m is disallowed because it's more
> complicated than it looks at first; this was discussed here:
> http://thread.gmane.org/gmane.comp.version-control.git/98825/focus=99206
Thanks for a reminder.
> I can't imagine why deletion should be prohibited as well, though.
I am not sure if it is a good idea to let "update-ref -d" work on a
symref, with or without --no-deref. There are cases where you want
to remove the pointer ("symbolic-ref -d" is there for that), and
there are cases where you want to remove the underlying ref (but of
course you can "update-ref -d" the underlying ref yourself). If
"update-ref -d" refused to work on a symref, we do not have to worry
about the confusion "which one is removed---the pointer, or the
pointee?"
> But I wonder why most delete_ref() calls in the code actually don't use
> the flag REF_NODEREF, thus deleting symref targets instead of the
> symrefs themselves. I may be missing something important here.
I suspect that is primarily because using a symref to represent
anything other than $GIT_DIR/HEAD and $GIT_DIR/refs/remotes/*/HEAD
is outside the normally supported use case and in the "may happen to
work" territory.
Having said all that, I think your patch is going in the right
direction. If somebody had a symbolic ref in refs/heads/, the
removal should remove it, not the pointee, which may not even
exist. Does "branch -d sym" work correctly with your patch when
refs/heads/sym is pointing at something that does not exist?
> ---
> builtin/branch.c | 2 +-
> t/t3200-branch.sh | 10 ++++++++++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index ffd2684..31af114 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -221,7 +221,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
> continue;
> }
>
> - if (delete_ref(name, sha1, 0)) {
> + if (delete_ref(name, sha1, REF_NODEREF)) {
> error(remote_branch
> ? _("Error deleting remote branch '%s'")
> : _("Error deleting branch '%s'"),
> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
> index 79c8d01..4b73406 100755
> --- a/t/t3200-branch.sh
> +++ b/t/t3200-branch.sh
> @@ -262,6 +262,16 @@ test_expect_success 'config information was renamed, too' \
> "test $(git config branch.s.dummy) = Hello &&
> test_must_fail git config branch.s/s/dummy"
>
> +test_expect_success 'deleting a symref' '
> + git branch target &&
> + git symbolic-ref refs/heads/symlink refs/heads/target &&
> +
> + git branch -d symlink &&
> +
> + test_path_is_file .git/refs/heads/target &&
> + test_path_is_missing .git/refs/heads/symlink
> +'
> +
> test_expect_success 'renaming a symref is not allowed' \
> '
> git symbolic-ref refs/heads/master2 refs/heads/master &&
next prev parent reply other threads:[~2012-10-16 16:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-15 8:50 BUG when trying to delete symbolic refs Johan Herland
2012-10-16 10:05 ` René Scharfe
2012-10-16 10:22 ` [PATCH] refs: lock symref that is to be deleted, not its target René Scharfe
2012-10-16 16:09 ` Junio C Hamano [this message]
2012-10-18 11:59 ` BUG when trying to delete symbolic refs René Scharfe
2012-10-18 12:02 ` [PATCH 1/5] branch: factor out check_branch_commit() René Scharfe
2012-10-18 12:04 ` [PATCH 2/5] branch: factor out delete_branch_config() René Scharfe
2012-10-18 12:05 ` [PATCH 3/5] branch: delete symref branch, not its target René Scharfe
2012-10-18 12:07 ` [PATCH 4/5] branch: skip commit checks when deleting symref branches René Scharfe
2012-10-18 21:34 ` Junio C Hamano
2012-10-21 10:40 ` [PATCH 0/2] Fix remaining issue when deleting symrefs Johan Herland
2012-10-21 10:40 ` [PATCH 1/2] t1400-update-ref: Add test verifying bug with symrefs in delete_ref() Johan Herland
2012-10-21 10:40 ` [PATCH 2/2] Fix failure to delete a packed ref through a symref Johan Herland
2012-10-21 17:46 ` René Scharfe
2012-10-21 19:09 ` Junio C Hamano
2012-10-18 12:08 ` [PATCH 5/5] branch: show targets of deleted symrefs, not sha1s René Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vr4oytn4q.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=johan@herland$(echo .)net \
--cc=rene.scharfe@lsrfire$(echo .)ath.cx \
--cc=vmiklos@suse$(echo .)cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox