From: Jeff King <peff@peff.net>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 8/8] refs: check refnames as fully qualified when resolving
Date: Fri, 3 May 2024 13:55:53 -0400 [thread overview]
Message-ID: <20240503175553.GG3631237@coredump.intra.peff.net> (raw)
In-Reply-To: <ZjDVLAKA0_4pTAS7@tanuki>
On Tue, Apr 30, 2024 at 01:25:32PM +0200, Patrick Steinhardt wrote:
> > 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?
> > 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
next prev parent reply other threads:[~2024-05-03 17:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 8:35 [PATCH 8/8] refs: check refnames as fully qualified when resolving Jeff King
2024-04-30 4:54 ` Patrick Steinhardt
2024-04-30 10:41 ` Jeff King
2024-04-30 11:25 ` Patrick Steinhardt
2024-05-03 17:55 ` Jeff King [this message]
2024-05-06 6:22 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240503175553.GG3631237@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.