Re: [PATCH 8/8] refs: check refnames as fully qualified when resolving

From: Jeff King <peff@peff.net>
Date: May 3, 2024, 17:55 UTC
Message-ID: <20240503175553.GG3631237@coredump.intra.peff.net>
In-Reply-To: <ZjDVLAKA0_4pTAS7@tanuki>

On Tue, Apr 30, 2024 at 01:25:32PM +0200, Patrick Steinhardt wrote:

Show 12 quoted lines

> > So this is where I will show my ignorance of reftables. I assume it
> > still has to implement FETCH_HEAD as a file (since it holds extra data).
> > But does it do the same for other names outside of "refs/"? I am
> > assuming not in the paragraph below.
> 
> No, that's why we originally introduced the "special refs" syntax, as
> defined in gitglossary(7). There are only two files that behave like
> refs, but circumvent the ref backend: FETCH_HEAD and MERGE_HEAD. Both of
> these have special syntax and carry additional metadata, and as such
> they cannot be stored generically in a ref backend.
> 
> All other root refs are stored via the ref backend.

OK, that matches what I guessed based on the existence of special refs. ;) Thanks for confirming.

Part of me does wonder if things would be simpler if ref backends only handled refs/*, and pseudo/special/root refs remained as their own thing in the filesystem. They're a limited set, so we don't really care about scaling in the same way. And their point is to be somewhat ephemeral, so even if you wanted to be clever with a replicated database-backed refs store, you probably don't care if CHERRY_PICK_HEAD goes away.

And it's not clear to me what the path forward is for scripts which poke at .git/* to determine repo state. For example, I think git-prompt.sh looks at CHERRY_PICK_HEAD and REVERT_HEAD to decide what we're doing. Maybe we just roll all of that into a command which returns all details of the repo state?

Show 8 quoted lines

> > So I think dropping REFFILES it would still pass, but we are not really
> > testing anything that interesting for reftables. That said, I would be
> > OK dropping the REFFILES in the name of simplicity and just documenting
> > it in the commit message.
> 
> Yeah, I'd prefer to drop it. We should only specify the REFFILES prereq
> as sparingly as possible to ensure that behaviour is as consistent as
> possible across the implementations.

Makes sense. I'll change that for my next re-roll (which probably won't be until next week, as I'll be offline for a bit).

-Peff