All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Andy Koppe <andy.koppe@gmail.com>
Cc: git@vger.kernel.org,  Patrick Steinhardt <ps@pks.im>,
	 Karthik Nayak <karthik.188@gmail.com>,
	 Julia Evans <julia@jvns.ca>
Subject: Re: [PATCH v3 3/5] doc: stop calling root refs pseudorefs
Date: Fri, 06 Nov 2026 15:08:15 -0800	[thread overview]
Message-ID: <xmqqzevld0dc.fsf@gitster.g> (raw)
In-Reply-To: <ac3ed53867d868c36a91f4c5c6be1fe2d874651d.1794000450.git.andy.koppe@gmail.com> (Andy Koppe's message of "Fri, 6 Nov 2026 21:31:06 +0000")

Andy Koppe <andy.koppe@gmail.com> writes:

> Several manual pages still use "pseudoref" in its old sense of any ref
> outside of "refs/", which the glossary now calls a root ref. Pseudorefs
> have since been restricted to FETCH_HEAD and MERGE_HEAD, which are not
> considered root refs.
>
> Replace "pseudoref" with "root ref" in those pages, giving HEAD and
> ORIG_HEAD as examples. In git-worktree(1), say that both root refs and
> pseudorefs are per-worktree, and drop the description of them as being
> directly under $GIT_DIR, because that does not apply to the reftable
> backend.

Thanks.  Clarification of this kind is very very much appreciated.

> diff --git a/Documentation/config/core.adoc b/Documentation/config/core.adoc
> index bdc74d291c..8f8fe36a58 100644
> --- a/Documentation/config/core.adoc
> +++ b/Documentation/config/core.adoc
> @@ -376,7 +376,7 @@ core.logAllRefUpdates::
>  	`refs/heads/`), remote refs (i.e. under `refs/remotes/`),
>  	note refs (i.e. under `refs/notes/`), and the symbolic ref `HEAD`.
>  	If it is set to `always`, then a missing reflog is automatically
> -	created for any ref under `refs/`.
> +	created for any ref, including root refs such as `ORIG_HEAD`.

We are witnessing a grave mistake getting corrected here.  Nice.

>  `--include-root-refs`::
> -	List root refs (`HEAD` and pseudorefs) apart from regular refs.
> +	Also list root refs, such as `HEAD` or `ORIG_HEAD`.

Good.

> diff --git a/Documentation/git-ls-remote.adoc b/Documentation/git-ls-remote.adoc
> index d71c4ab3e2..7ce7df3149 100644
> --- a/Documentation/git-ls-remote.adoc
> +++ b/Documentation/git-ls-remote.adoc
> @@ -35,7 +35,7 @@ OPTIONS
>  	with other git subcommands.
>  
>  --refs::
> -	Do not show peeled tags or pseudorefs like `HEAD` in the output.
> +	Do not show peeled tags or refs outside `refs/`.

Hmph, is there a reason for saying "refs outside `refs/`" (as
opposed to "root refs") here?

I _think_ (correct me if I am not remembering right) by default
ls-remote shows everything under refs/ (with peeled tags) and HEAD.
It is not even "normal refs including root refs", i.e. ORIG_HEAD is
not shown.  With "--refs", of course ORIG_HEAD is still not shown,
but it stops HEAD from getting shown.  So "do not show root refs" or
"do not show refs outside refs/" are equally slightly broader than
needed (meaning: with or without this option restricting further,
any root ref other than HEAD, like ORIG_HEAD, are not shown anyway).

Do we even say what are normally shown in this manual page?  Perhaps
we would want to update the description to say something like

    DESCRIPTION
    -----------
    Displays references available in a remote repository along with
    the associated commit IDs.  By default, all normal refs under
    `refs/` and `HEAD` are shown.  For each tag object, the tag
    itself and the object it tags (colloquially called `peeled`) are
    shown.

upfront, before going to the OPTIONS section to tell the users how
to tweak that default?

> @@ -118,7 +118,7 @@ line shows the name of the object the tag points at.
>  EXAMPLES
>  --------
>  
> -* List all references (including symbolics and pseudorefs), peeling
> +* List all references (including `HEAD` and symbolic refs), peeling
>    tags:

Here, mentioning symbolic refs as if they are anything special is
misleading, no?  Symbolic or non-symbolic, refs are refs.

On the other hand, "all references" should logically include
(normal) refs under `refs/` hierarchy plus "root refs", so "List all
references" is technically incorrect.  Perhaps give it a bit more
correction, e.g.,

    List all refs under `refs/` and `HEAD`, peeling tags.

which would make it in line with the updated DESCRIPTION suggested
above.

> diff --git a/Documentation/git-update-ref.adoc b/Documentation/git-update-ref.adoc
> index 37a5019a8b..c775334230 100644
> --- a/Documentation/git-update-ref.adoc
> +++ b/Documentation/git-update-ref.adoc
> @@ -163,13 +163,12 @@ still see a subset of the modifications.
>  
>  LOGGING UPDATES
>  ---------------
> -If config parameter "core.logAllRefUpdates" is true and the ref is one
> -under "refs/heads/", "refs/remotes/", "refs/notes/", or a pseudoref
> -like HEAD or ORIG_HEAD; or the file "$GIT_DIR/logs/<ref>" exists then
> -`git update-ref` will append a line to the log file
> -"$GIT_DIR/logs/<ref>" (dereferencing all symbolic refs before creating
> -the log name) describing the change in ref value.  Log lines are
> -formatted as:
> +If config parameter "core.logAllRefUpdates" is true and the ref is
> +HEAD or one under "refs/heads/", "refs/remotes/" or "refs/notes/", or
> +if the file "$GIT_DIR/logs/<ref>" exists, then `git update-ref` will
> +append a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
> +symbolic refs before creating the log name) describing the change in
> +ref value.  Log lines are formatted as:

This mention of files and lines may be obsolete in the world with
reftable, but I am perfectly fine to leave the correction on that
front to another series, and concentrate only on "what is a ref?
what is a root ref?  and what is a pseudoref?" clarification and
nothing else.  And for that purpose, the updated text is a perfect
fit.

> diff --git a/Documentation/git-worktree.adoc b/Documentation/git-worktree.adoc
> ...
> +In general, all root refs and pseudorefs are per-worktree and all refs
> +starting with `refs/` are shared, except for refs with the following prefixes:
> +
> + - `refs/bisect/`
> +
> + - `refs/rewritten/`
> +
> + - `refs/worktree/`

Good; the same comment on "are these frozen?" applies.

> diff --git a/Documentation/gitdatamodel.adoc b/Documentation/gitdatamodel.adoc
> index 8d9be02036..2e44cc5003 100644
> --- a/Documentation/gitdatamodel.adoc
> +++ b/Documentation/gitdatamodel.adoc
> @@ -211,15 +211,28 @@ remote-tracking branches: `refs/remotes/<remote>/<branch>`::
>  default branch. This is the branch that `git clone` checks out by default.
>  
>  [[other-refs]]
> -Other references::
> +other references::

Nice attention to the detail.

>      Git tools may create references anywhere under `refs/`.
>      For example, linkgit:git-stash[1], linkgit:git-bisect[1],
>      and linkgit:git-notes[1] all create their own references
>      in `refs/stash`, `refs/bisect`, etc.
>      Third-party Git tools may also create their own references.
> -+
> -Git may also create references other than `HEAD` at the base of the
> -hierarchy, like `ORIG_HEAD`.

Good to get rid of this and adding a separate entry for root refs.

> +
> +[[root-refs]]
> +root refs::
> +    Git may create references other than `HEAD` at the root of the hierarchy,
> +    for example `ORIG_HEAD` or `REBASE_HEAD`.

Is this a good place to talk about their naming conventions?  At
least we want to have a reference to where we talk about it, I
think, just like you did one for pseudorefs below.

> +[[pseudorefs]]
> +pseudorefs::
> +    linkgit:git-fetch[1], linkgit:git-merge[1] and linkgit:git-pull[1]
> +    create the so-called pseudorefs `FETCH_HEAD` and `MERGE_HEAD`.
> +    They are not references as such, because they are not stored by the
> +    ref backend, but they can nevertheless be used to refer to objects in
> +    commands such as linkgit:git-log[1] and linkgit:git-diff[1].
> +
> +See linkgit:gitglossary[7] for further details on root refs and
> +pseudorefs.

Great.  I do not see a need for so-called here.  As technical term,
pseudorefs, references, and root refs, all are officially sanctioned
words, and there is nothing so-called about them.

> diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> index bd9f345690..822604278a 100644
> --- a/Documentation/rev-list-options.adoc
> +++ b/Documentation/rev-list-options.adoc
> @@ -350,8 +350,8 @@ Under `--pretty=reference`, this information will not be shown at all.
>  
>  `--merge`::
>  	Show commits touching conflicted paths in the range `HEAD...<other>`,
> -	where `<other>` is the first existing pseudoref in `MERGE_HEAD`,
> -	`CHERRY_PICK_HEAD`, `REVERT_HEAD` or `REBASE_HEAD`. Only works
> +	where `<other>` is the first of `MERGE_HEAD`, `CHERRY_PICK_HEAD`,
> +	`REVERT_HEAD` or `REBASE_HEAD` that exists. Only works

Phrasing "existing pseudoref" in the original was wrong, but the
updated text feels a bit incomplete.  "... where <other> is the
first ref among X, Y, ... Z that exist" or something like that?

Overall, very welcome clarificaiton.

  reply	other threads:[~2026-11-06 23:08 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 21:28 [PATCH 0/5] root refs vs pseudorefs Andy Koppe
2026-10-22 21:28 ` [PATCH 1/5] doc: glossary: add root ref and clarify pseudorefs Andy Koppe
2026-10-22 22:07   ` Junio C Hamano
2026-10-23  7:41   ` Patrick Steinhardt
2026-11-01 23:18     ` Andy Koppe
2026-10-22 21:28 ` [PATCH 2/5] doc: glossary: update per-worktree refs Andy Koppe
2026-10-23  7:41   ` Patrick Steinhardt
2026-11-01 23:26     ` Andy Koppe
2026-10-22 21:28 ` [PATCH 3/5] doc: stop calling root refs pseudorefs Andy Koppe
2026-10-23  7:41   ` Patrick Steinhardt
2026-11-01 23:44     ` Andy Koppe
2026-10-22 21:28 ` [PATCH 4/5] refs: " Andy Koppe
2026-10-23  7:41   ` Patrick Steinhardt
2026-11-01 23:46     ` Andy Koppe
2026-10-22 21:28 ` [PATCH 5/5] t: " Andy Koppe
2026-10-22 22:18 ` [PATCH 0/5] root refs vs pseudorefs Junio C Hamano
2026-10-23 13:21 ` Julia Evans
2026-11-01 23:07   ` Andy Koppe
2026-11-01 23:03 ` [PATCH v2 " Andy Koppe
2026-11-02 18:19   ` Julia Evans
2026-11-02 19:47     ` Andy Koppe
2026-11-02 21:00       ` Julia Evans
2026-11-02 22:19         ` Andy Koppe
2026-11-03 14:36           ` Julia Evans
2026-11-06 22:02             ` Andy Koppe
2026-11-02 21:49     ` Junio C Hamano
2026-11-01 23:03 ` [PATCH v2 1/5] doc: glossary: add root ref and clarify pseudorefs Andy Koppe
2026-11-03 11:29   ` Patrick Steinhardt
2026-11-03 18:30     ` Junio C Hamano
2026-11-01 23:03 ` [PATCH v2 2/5] doc: glossary: update per-worktree refs Andy Koppe
2026-11-03 11:29   ` Patrick Steinhardt
2026-11-01 23:03 ` [PATCH v2 3/5] doc: stop calling root refs pseudorefs Andy Koppe
2026-11-03 11:30   ` Patrick Steinhardt
2026-11-01 23:03 ` [PATCH v2 4/5] refs: " Andy Koppe
2026-11-01 23:03 ` [PATCH v2 5/5] t: " Andy Koppe
2026-11-06 21:31 ` [PATCH v3 0/5] root refs vs pseudorefs Andy Koppe
2026-11-06 21:31   ` [PATCH v3 1/5] doc: glossary: add root ref and clarify pseudorefs Andy Koppe
2026-11-06 22:13     ` Junio C Hamano
2026-11-06 21:31   ` [PATCH v3 2/5] doc: glossary: update per-worktree refs Andy Koppe
2026-11-06 22:16     ` Junio C Hamano
2026-11-06 21:31   ` [PATCH v3 3/5] doc: stop calling root refs pseudorefs Andy Koppe
2026-11-06 23:08     ` Junio C Hamano [this message]
2026-11-06 21:31   ` [PATCH v3 4/5] refs: " Andy Koppe
2026-11-06 23:16     ` Junio C Hamano
2026-11-06 21:31   ` [PATCH v3 5/5] t: " Andy Koppe

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=xmqqzevld0dc.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=andy.koppe@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=julia@jvns.ca \
    --cc=karthik.188@gmail.com \
    --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.