git.vger.kernel.org archive mirror
 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 1/5] git.txt: HEAD is not that special
Date: Mon, 18 Dec 2023 08:26:40 -0800	[thread overview]
Message-ID: <xmqqplz3h3y7.fsf@gitster.g> (raw)
In-Reply-To: <ZYAGyLH4nm4TebA_@tanuki> (Patrick Steinhardt's message of "Mon, 18 Dec 2023 09:46:00 +0100")

Patrick Steinhardt <ps@pks.im> writes:

>>  Named pointers called refs mark interesting points in history.  A ref
>> -may contain the SHA-1 name of an object or the name of another ref.  Refs
>> -with names beginning `ref/head/` contain the SHA-1 name of the most
>> +may contain the SHA-1 name of an object or the name of another ref (the
>> +latter is called a "symbolic ref").
>
> On a tangent: While we have a name for symbolic refs, do we also have a
> name for non-symbolic refs? I often use the term "direct ref" to clearly
> distinguish them from symbolic refs, but it's of course not defined in
> our glossary.

You may find me saying "normal ref", "regular ref", or somesuch when
it is not clear from the context if you dig the list archive.
"direct" is a nice word, especially it would give us a good pair of
terms if we are to change "symbolic" to "indirect", but since we are
not going to do so, I am not sure the contrast between "direct" and
"symbolic" would make such a good pair.

But quite honestly I rarely felt a need for a specific term, as it
is fairly clear from the context, e.g.

 * "From a ref, we locate an object using the object name it
   records and use the object"

   A statement written from the point of view of the consumer of
   object name, it does not matter if the object name is directly
   found in the ref, or indirection is involved to find such a
   concrete ref that records an object name by following the
   original symbolic ref.

 * "A ref usually stores an object name, but it can also be a
   symbolic ref that points at another ref, in which case, asking
   what object such a symbolic ref points at would yield the object
   the other ref points at".

So I dunno.

>> +Refs with names beginning `ref/head/` contain the SHA-1 name of the most
>>  recent commit (or "head") of a branch under development.  SHA-1 names of
>> -tags of interest are stored under `ref/tags/`.  A special ref named
>> +tags of interest are stored under `ref/tags/`.  A symbolic ref named
>>  `HEAD` contains the name of the currently checked-out branch.
>
> I was briefly wondering whether we also want to replace SHA-1 with
> "object hash" while at it, but it's certainly out of the scope of this
> patch series.

Yup, there still are too many reference to SHA-1 (and "sha1", which
is even worse), and it is not a focus of this series.

Thanks.

  reply	other threads:[~2023-12-18 16:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-15 20:32 [PATCH 0/5] make room for "special ref" Junio C Hamano
2023-12-15 20:32 ` [PATCH 1/5] git.txt: HEAD is not that special Junio C Hamano
2023-12-15 21:57   ` Ramsay Jones
2023-12-15 22:06     ` Junio C Hamano
2023-12-15 22:19       ` Junio C Hamano
2023-12-15 22:28         ` [PATCH] doc: format.notes specify a ref under refs/notes/ hierarchy Junio C Hamano
2023-12-18  8:06           ` Patrick Steinhardt
2023-12-18 16:16             ` Junio C Hamano
2023-12-19 15:33               ` Jiang Xin
2023-12-15 22:37         ` [PATCH 1/5] git.txt: HEAD is not that special Ramsay Jones
2023-12-18  8:46   ` Patrick Steinhardt
2023-12-18 16:26     ` Junio C Hamano [this message]
2023-12-15 20:32 ` [PATCH 2/5] git-bisect.txt: BISECT_HEAD " Junio C Hamano
2023-12-15 20:32 ` [PATCH 3/5] refs.h: HEAD " Junio C Hamano
2023-12-16 10:03   ` Andy Koppe
2023-12-15 20:32 ` [PATCH 4/5] docs: AUTO_MERGE " Junio C Hamano
2023-12-15 20:32 ` [PATCH 5/5] docs: MERGE_AUTOSTASH " Junio C Hamano
2023-12-16 11:04   ` Andy Koppe
2023-12-15 21:21 ` [PATCH 0/5] make room for "special ref" Junio C Hamano
2023-12-15 22:44   ` Ramsay Jones
2023-12-16  0:44     ` Junio C Hamano
2023-12-18  8:41       ` Patrick Steinhardt
2023-12-16 10:20     ` Andy Koppe
2023-12-18  8:24       ` Patrick Steinhardt
2023-12-16 10:56 ` Andy Koppe
2023-12-18  8:56 ` 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=xmqqplz3h3y7.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).