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

From: Patrick Steinhardt <ps@pks.im>
Date: May 2, 2024, 08:07 UTC
Message-ID: <ZjNJ1w-hPyAxh2i9@tanuki>
In-Reply-To: <xmqqttjiy5hq.fsf@gitster.g>

On Tue, Apr 30, 2024 at 01:12:33PM -0700, Junio C Hamano wrote:

Show 15 quoted lines

> 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