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

[Patrick Steinhardt <ps@pks.im>]

[-- 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]