All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 6/7] refs: redefine special refs
Date: Fri, 19 Jan 2024 12:28:29 -0800	[thread overview]
Message-ID: <xmqq7ck5jceq.fsf@gitster.g> (raw)
In-Reply-To: <a4b4dd51f81fdf65f79b9afc3bd85109817ea128.1705659748.git.ps@pks.im> (Patrick Steinhardt's message of "Fri, 19 Jan 2024 11:40:24 +0100")

Patrick Steinhardt <ps@pks.im> writes:

> Now that our list of special refs really only contains refs which have
> actually-special semantics, let's redefine what makes a special ref.

Yay.

>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  refs.c | 33 +++++++--------------------------
>  1 file changed, 7 insertions(+), 26 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 047c81b1c1..08a900a047 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1839,13 +1839,10 @@ static int refs_read_special_head(struct ref_store *ref_store,
>  static int is_special_ref(const char *refname)
>  {
>  	/*
> -	 * Special references get written and read directly via the filesystem
> -	 * by the subsystems that create them. Thus, they must not go through
> -	 * the reference backend but must instead be read directly. It is
> -	 * arguable whether this behaviour is sensible, or whether it's simply
> -	 * a leaky abstraction enabled by us only having a single reference
> -	 * backend implementation. But at least for a subset of references it
> -	 * indeed does make sense to treat them specially:
> +	 * Special references are refs that have different semantics compared
> +	 * to "normal" refs. These refs can thus not be stored in the ref
> +	 * backend, but must always be accessed via the filesystem. The
> +	 * following refs are special:
>  	 *
>  	 * - FETCH_HEAD may contain multiple object IDs, and each one of them
>  	 *   carries additional metadata like where it came from.
> @@ -1853,25 +1850,9 @@ static int is_special_ref(const char *refname)
>  	 * - MERGE_HEAD may contain multiple object IDs when merging multiple
>  	 *   heads.
>  	 *
> -	 * There are some exceptions that you might expect to see on this list
> -	 * but which are handled exclusively via the reference backend:
> -	 *
> -	 * - BISECT_EXPECTED_REV
> -	 *
> -	 * - CHERRY_PICK_HEAD
> -	 *
> -	 * - HEAD
> -	 *
> -	 * - ORIG_HEAD
> -	 *
> -	 * - "rebase-apply/" and "rebase-merge/" contain all of the state for
> -	 *   rebases, including some reference-like files. These are
> -	 *   exclusively read and written via the filesystem and never go
> -	 *   through the refdb.
> -	 *
> -	 * Writing or deleting references must consistently go either through
> -	 * the filesystem (special refs) or through the reference backend
> -	 * (normal ones).
> +	 * Reading, writing or deleting references must consistently go either
> +	 * through the filesystem (special refs) or through the reference
> +	 * backend (normal ones).
>  	 */
>  	static const char * const special_refs[] = {
>  		"FETCH_HEAD",

  reply	other threads:[~2024-01-19 20:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 10:39 [PATCH 0/7] refs: convert special refs to become normal pseudo-refs Patrick Steinhardt
2024-01-19 10:39 ` [PATCH 1/7] sequencer: clean up pseudo refs with REF_NO_DEREF Patrick Steinhardt
2024-01-19 19:14   ` Junio C Hamano
2024-01-22 10:36     ` Patrick Steinhardt
2024-01-22 11:49   ` Karthik Nayak
2024-01-22 12:28     ` Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 2/7] sequencer: delete REBASE_HEAD in correct repo when picking commits Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 3/7] refs: convert AUTO_MERGE to become a normal pseudo-ref Patrick Steinhardt
2024-01-19 19:28   ` Junio C Hamano
2024-01-22 10:45     ` Patrick Steinhardt
2024-01-24  3:19       ` Elijah Newren
2024-01-22 12:02   ` Karthik Nayak
2024-01-19 10:40 ` [PATCH 4/7] sequencer: introduce functions to handle autostashes via refs Patrick Steinhardt
2024-01-19 20:09   ` Junio C Hamano
2024-01-22 10:51     ` Patrick Steinhardt
2024-01-22 19:54       ` Phillip Wood
2024-01-22 20:16         ` Junio C Hamano
2024-01-19 10:40 ` [PATCH 5/7] refs: convert MERGE_AUTOSTASH to become a normal pseudo-ref Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 6/7] refs: redefine special refs Patrick Steinhardt
2024-01-19 20:28   ` Junio C Hamano [this message]
2024-01-19 10:40 ` [PATCH 7/7] Documentation: add "special refs" to the glossary Patrick Steinhardt
2024-01-23 16:27   ` Phillip Wood
2024-01-24  9:05     ` 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=xmqq7ck5jceq.fsf@gitster.g \
    --to=gitster@pobox.com \
    --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.