Re: [PATCH v2 01/10] Documentation/glossary: redefine pseudorefs as special refs

Patrick Steinhardt
2024-05-02T08:07:57Z

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Tue, Apr 30, 2024 at 01:12:33PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > Let's address this mess and return the pseudoref terminology back to its
> > original intent: a ref that sometimes behave like a ref, but which isn't
> > really a ref because it gets written to the filesystem directly. Or in
> > other words, let's redefine pseudorefs to match the current definition
> > of special refs. As special refs and pseudorefs are now the same per
> > definition, we can drop the "special refs" term again. It's not exposed
> > to our users and thus they wouldn't ever encounter that term anyway.
>
> Good intentions.
>
> I do not agree with "the ones at the root should not be special" at
> all, though. We need to reject names like 'config' somehow, as long
> as there are users who use files backend.

Oh, yes, I totally agree and thought I'd mentioned this in the message.
But it seems like I only mention this in a subsequent message. Let me
add a hint to the commit message that mentions that a subsequent commit
will clearly define "root refs".

In any case, root refs should not be special regarding their behaviour,
but should have a strict naming schema:

- Only uppercase letters or underscores.

- Must end with "_HEAD" or be called "HEAD".

- There is an exhaustive list of legacy root refs that don't conform
to this naming schema, like "AUTO_MERGE". This list shall not be
extended in the future.

This explanation is added in patch 3.

Patrick