All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Toon Claes <toon@iotcl.com>
Cc: peff@peff.net,  git@vger.kernel.org
Subject: Re: [PATCH 4/4] refs: do not clobber dangling symrefs
Date: Mon, 22 Sep 2025 08:54:34 -0700	[thread overview]
Message-ID: <xmqqwm5qv5xh.fsf@gitster.g> (raw)
In-Reply-To: <20250922122332.584428-1-toon@iotcl.com> (Toon Claes's message of "Mon, 22 Sep 2025 14:23:32 +0200")

Toon Claes <toon@iotcl.com> writes:

> We use `update FOO_HEAD 000...000 000..000` to delete a symref, if that symref
> is dangling (otherwise the old oid would have resolved to something). I've
> attached a patch that would allow this (on top of your patches). Do you think it
> makes sense to allow this scenario?
> ...
> +	test_when_finished "git update-ref -d refs/heads/dangling" &&
> +	git symbolic-ref refs/heads/dangling refs/heads/does-not-exist &&
> +	echo "update refs/heads/dangling $Z $Z" >stdin &&
> +	git update-ref --no-deref --stdin <stdin &&

"git update-ref --help" seems to show that the "--stdin" mode has a
separate command that is designed for exactly the purpose of removing
a symbolic ref, though.  If you are changing the semantics of "update"
to make it safer while dealing with a dangling symbolic ref, do you
also need to touch the code path that handles "symref-delete" command?

> +	test_must_fail git rev-parse --verify refs/heads/dangling &&
> +	test_must_fail git rev-parse --verify refs/heads/does-not-exist
> +'
> +
>  test_done
> --
> 2.51.0

  reply	other threads:[~2025-09-22 15:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-19 19:20 [PATCH 0/4] dangling symrefs and fetchRemoteHEAD=create Jeff King
2025-08-19 19:23 ` Jeff King
2025-08-19 19:24 ` [PATCH 1/4] t5510: make confusing config cleanup more explicit Jeff King
2025-08-19 20:03   ` Eric Sunshine
2025-08-19 20:16     ` Eric Sunshine
2025-08-19 20:53     ` Jeff King
2025-08-19 19:26 ` [PATCH 2/4] t5510: stop changing top-level working directory Jeff King
2025-08-19 19:27 ` [PATCH 3/4] t5510: prefer "git -C" to subshell for followRemoteHEAD tests Jeff King
2025-08-24 19:41   ` SZEDER Gábor
2025-08-25 15:46     ` Junio C Hamano
2025-08-26  3:44       ` Jeff King
2025-08-26 14:58         ` Junio C Hamano
2025-08-19 19:29 ` [PATCH 4/4] refs: do not clobber dangling symrefs Jeff King
2025-08-20  7:27   ` Patrick Steinhardt
2025-08-20 19:14     ` Jeff King
2025-09-22 12:23   ` Toon Claes
2025-09-22 15:54     ` Junio C Hamano [this message]
2025-09-22 17:21       ` Jeff King
2025-09-22 17:35         ` Junio C Hamano
2025-09-22 17:12     ` Jeff King
2025-09-23  9:36       ` Toon Claes
2025-09-23 17:33         ` Jeff King

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=xmqqwm5qv5xh.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=toon@iotcl.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.