From: Junio C Hamano <gitster@pobox.com>
To: "Julia Evans" <julia@jvns.ca>
Cc: "Andy Koppe" <andy.koppe@gmail.com>,
git@vger.kernel.org, "Patrick Steinhardt" <ps@pks.im>,
"Karthik Nayak" <karthik.188@gmail.com>
Subject: Re: [PATCH v2 0/5] root refs vs pseudorefs
Date: Mon, 02 Nov 2026 13:49:00 -0800 [thread overview]
Message-ID: <xmqqcxsmhpkj.fsf@gitster.g> (raw)
In-Reply-To: <840bc117-75e9-4d63-882e-3831156871a3@app.fastmail.com> (Julia Evans's message of "Mon, 02 Nov 2026 13:19:57 -0500")
"Julia Evans" <julia@jvns.ca> writes:
... 200 lines of quoted material omitted ...
>> ++[[pseudorefs]]
>> ++pseudorefs::
>> ++ linkgit:git-fetch[1] and linkgit:git-merge[1] create the
>> so-called
>> ++ pseudorefs `FETCH_HEAD` and `MERGE_HEAD`. They are not
>> references as
>> ++ such, as they are not stored in the same way, but they can
>> nevertheless
>
> When I look at my .git directory during a merge conflict, I see these
> files:
>
> $ ls .git | grep HEAD
> FETCH_HEAD
> HEAD
> MERGE_HEAD
> ORIG_HEAD
>
> From the above, it sounds like ORIG_HEAD is a "root ref" and
> MERGE_HEAD is a "pseudoref", but naively it does look like
> they're stored in the same way. What's the difference?
A pseudoref cannot be treated as a true ref because it can describe
multiple objects. If you force it to be interpreted as an object,
you will still get one of the objects, but that is not the primary
way it is designed to be used. FETCH_HEAD even describes the nature
of each object, e.g.,
a018953...4 branch 'maint' of gitolite.kernel.org:/pub/scm/git/git
8d1b215...8 not-for-merge branch 'master' of gitolite.kernel.org:/pub/scm/git/git
882cbad...5 not-for-merge branch 'next' of gitolite.kernel.org:/pub/scm/git/git
4231a2f...4 not-for-merge branch 'jch' of gitolite.kernel.org:/pub/scm/git/git
2fa90fe...8 not-for-merge branch 'seen' of gitolite.kernel.org:/pub/scm/git/git
The other kind, just like a normal ref, describes one and only one
object. The only special trait it has is that it is outside the
refs/ hierarchy, so it may be a slight misnomer to call them "root"
refs. We do accept $GIT_DIR/ORIG_HEAD as if it were a real ref, but
if we did:
$ mkdir -p .git/foo/bar
$ git rev-parse HEAD~24 >.git/foo/bar/baz
$ git show -s foo/bar/baz
we would end up treating "foo/bar/baz" as if it were a real ref,
too, with exactly the same mechanism used to treat ORIG_HEAD.
The only difference between .git/ORIG_HEAD and .git/foo/bar/baz in
the above example is that we _do_ create "root" refs ourselves,
while we do not create such funky things like foo/bar/baz (hence
they do not deserve a name, and such "use" may suddenly break
without notice).
By the way, *please* trim your quote. Having to scroll past 200
lines of material that are totally irrelevant to understanding your
comment is a real pain.
Thanks.
next prev parent reply other threads:[~2026-11-02 21:49 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 [this message]
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
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=xmqqcxsmhpkj.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.