Re: [PATCH 7/8] refs: add 'update-symref' command to 'update-ref'

From: Chris Torek <chris.torek@gmail.com>
Date: Mar 31, 2024, 22:27 UTC
Message-ID: <CAPx1GvdXdH3OdY1nC2ijVSdpWfg8jn5=j0KB+Wgv70wWeCNH5g@mail.gmail.com>
In-Reply-To: <xmqqy19yf40l.fsf@gitster.g>

On Sun, Mar 31, 2024 at 3:09 PM Junio C Hamano <gitster@pobox.com> wrote:

> ... we are giving to "update-symref" is not an object name, but a
> refname (i.e. the target of the symref at <ref> points at), so
> "newvalue" -> "new-ref" or something is needed.

I kept this line just to say, I agree on all of the above ...

Show 6 quoted lines

> Existing "update" command can be used to create (by having "zero"
> <old-oid>) and to delete (by having "zero" <new-oid>), but we still
> have "create" and "delete" separately.  Given that we are teaching
> the command to also work with symrefs by adding command(s) for
> symrefs to an existing vocabulary, we should offer "create-symref"
> and "delete-symref" for consistency between refs and symrefs.

.. and on this, but:

Show 17 quoted lines

> It probably is a good idea to allow "update-symref" to also create
> and delete a symref in similar ways with the existing "update"
> allows creation and deletion of a ref.  An "zero" <old-ref> may be
> an update that can happen only when the <ref> does not exist, i.e.,
> creation, and an "zero" <new-ref> may be an update that makes <ref>
> disappear.
>
> "zero" value in the context of refs is a 0{40} object name (side
> note: we have an explicit mention of 40 in the doc, which needs to
> be updated eventually, probably outside this series).  But in the
> new context of symrefs, a safe "zero" value needs to be picked
> carefully.  An empty string may not work well syntactically
> especially in the `-z` format, because you cannot tell if
>
>         update-symref NUL HEAD NUL refs/heads/main NUL NUL
>
> wants to say that <old-ref> is an empty string, or if it is missing.

For these reasons, I'd suggest that the all-zero hash be officially deprecated in favor of create/delete and of course create-symref and delete-symref. Of course, compatibility requires some sort of support for the old system for some time. As to whether that means something like the suggestion of ".missing" etc, I have no particular opinion -- but since the symref options are new, they would not *need* symmetric options, if we just say that "update-symref" cannot create or delete a symref.

Meanwhile, for testing purposes I was curious as to what happens if you ask `git update-ref` to delete an existing symref, so after creating a test repository:

$ git branch
* main
  symref -> main
$ git update-ref --stdin
delete refs/heads/symref
$ git branch

Whoops, this doesn't look good...

Restoring the branch name (I had saved the hash ID Just In Case):

$ echo d88ee82e6a5c29c95f712030f5efc9d43116ae79 > .git/refs/heads/main

brings things back, after which this works properly:

$ git branch -d symref
Deleted branch symref (was refs/heads/main).
$ git branch
* main

If this (deleting the target of the symref when using "delete") is a bug, and I think it is, that's a separate topic of course...

Chris