On Sun, Mar 31, 2024 at 06:31:14PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
> > Chris Torek <chris.torek@xxxxxxxxx> writes:
> >
> >> 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.
> >
> > I love that simplicity.
>
> Having said that, the loose "update that can create or delete" may
> actually be used by applications that do not care about overwriting
> competing operation, so I am not sure if we can easily deprecate
> that mode of operation. Saying "update refs/heads/next to point at
> this object" and have it created if it does not exist may be handy
> for some loosely written applications.
I wouldn't say "loosely written here". I certainly know that we do use
these implicit modes in Gitaly, and we have conciously chosen them
because they have been supported by Git all along. It simply makes our
lifes easier when we don't have to special-case creations and deletions
in any way.
So I'd really not want those to go away or become deprecated.
Patrick
> So perhaps we can say "update with a concrete <old-oid> will ensure
> that the <ref> poitns at <old-oid> before proceeding, but update
> with 0{40} as <old-oid> to ensure creation is deprecated. update
> with 0{40} as <new-oid> as deletion is also deprecated. Use create
> and delete for these two deprecated operation modes".
>
> This assumes that create and delete currently ensures that what is
> asked to be created does not exist, and what is asked to be deleted
> does exist, before the operation. If we are loosely doing these two
> operations, then we cannot easily deprecate the checking-update,
> without breaking existing users.
>
> As {create,update,delete,verify}-symref do not exist yet, we can
> start with the right semantics from day one. "update-symref" will
> accept a <old-ref> only to ensure that the symref is pointing to
> that ref and there is no "zero" value based creation/deletion
> validation offered via "update-symref". "create-symref" will error
> out if the ref asked to be created already exists, "delete-symref"
> will error out if the ref asked to be deleted does not exist.
>
Attachment:
signature.asc
Description: PGP signature
