From: Patrick Steinhardt <ps@pks.im>
To: Andy Koppe <andy.koppe@gmail.com>
Cc: git@vger.kernel.org, Karthik Nayak <karthik.188@gmail.com>,
Julia Evans <julia@jvns.ca>
Subject: Re: [PATCH 3/5] doc: stop calling root refs pseudorefs
Date: Fri, 23 Oct 2026 09:41:54 +0200 [thread overview]
Message-ID: <atsPwpbD3YqmBds_@pks.im> (raw)
In-Reply-To: <20261022212903.177261-4-andy.koppe@gmail.com>
On Thu, Oct 22, 2026 at 10:28:51PM +0100, Andy Koppe wrote:
> 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
It's kind of hard to understand how the ANDs and ORs play together.
Like, does the config parameter extend to all subsequent ORs? That's not
really a new issue though.
> +append a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
Also, this infomation about "$GIT_DIR/logs/<ref>" is out-of-date, as the
reftable backend doesn't store its reflogs in there.
I wonder whether we should maybe just stop explaining how
"core.logAllRefUpdates" works and instead refer to git-config(1).
> diff --git a/Documentation/git-worktree.adoc b/Documentation/git-worktree.adoc
> index e6e77252ab..f0eb6d4137 100644
> --- a/Documentation/git-worktree.adoc
> +++ b/Documentation/git-worktree.adoc
> @@ -303,11 +303,10 @@ but others are specific to an individual worktree. One example is `HEAD`,
> which is different for each worktree. This section is about the sharing
> rules and how to access refs of one worktree from another.
>
> -In general, all pseudo refs are per-worktree and all refs starting with
> -`refs/` are shared. Pseudo refs are ones like `HEAD` which are directly
> -under `$GIT_DIR` instead of inside `$GIT_DIR/refs`. There are exceptions,
> -however: refs inside `refs/bisect`, `refs/worktree` and `refs/rewritten` are
> -not shared.
> +In general, all root refs and pseudorefs are per-worktree and all refs
> +starting with `refs/` are shared. There are exceptions, however: refs
> +inside `refs/bisect`, `refs/worktree` and `refs/rewritten` are not
> +shared.
It might make sense to have a bulleted list here, same as I proposed in
a preceding patch.
Patrick
next prev parent reply other threads:[~2026-10-23 7:41 UTC|newest]
Thread overview: 13+ 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-10-22 21:28 ` [PATCH 2/5] doc: glossary: update per-worktree refs Andy Koppe
2026-10-23 7:41 ` Patrick Steinhardt
2026-10-22 21:28 ` [PATCH 3/5] doc: stop calling root refs pseudorefs Andy Koppe
2026-10-23 7:41 ` Patrick Steinhardt [this message]
2026-10-22 21:28 ` [PATCH 4/5] refs: " Andy Koppe
2026-10-23 7:41 ` Patrick Steinhardt
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
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=atsPwpbD3YqmBds_@pks.im \
--to=ps@pks.im \
--cc=andy.koppe@gmail.com \
--cc=git@vger.kernel.org \
--cc=julia@jvns.ca \
--cc=karthik.188@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox