git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Victoria Dye via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  ps@pks.im,  Victoria Dye <vdye@github.com>
Subject: Re: [PATCH] glossary: add definitions for dereference & peel
Date: Fri, 10 Nov 2023 09:22:41 +0900	[thread overview]
Message-ID: <xmqq1qcyxxri.fsf@gitster.g> (raw)
In-Reply-To: <pull.1610.git.1699574277143.gitgitgadget@gmail.com> (Victoria Dye via GitGitGadget's message of "Thu, 09 Nov 2023 23:57:57 +0000")

"Victoria Dye via GitGitGadget" <gitgitgadget@gmail.com> writes:

> @@ -125,6 +124,24 @@ to point at the new commit.
>  	dangling object has no references to it from any
>  	reference or <<def_object,object>> in the <<def_repository,repository>>.
>  
> +[[def_dereference]]dereference::
> +	Referring to a <<def_symref,symbolic ref>>: the action of accessing the
> +	<<def_ref,reference>> pointed at by a symbolic ref. Recursive
> +	dereferencing involves repeating the aforementioned process on the
> +	resulting ref until a non-symbolic reference is found.
> ++
> +Referring to a <<def_tag_object,tag object>>: the action of accessing the
> +<<def_object,object>> a tag points at. Tags are recursively dereferenced by
> +repeating the operation on the result object until the result has either a
> +specified <<def_object_type,object type>> (where applicable) or any non-"tag"
> +object type.
> ++

All of the above makes sense.

I would casually mention "peeling" here with cross reference,
if I were writing this section.  There already is enough cross
reference in the other direction pointing this way.

> +Referring to a <<def_commit_object,commit object>>: the action of accessing
> +the commit's tree object. Commits cannot be dereferenced recursively.

I personally consider this is weird misuse of the verb and is rarely
used, but we see it in the description of tree-ish below.

> +Unless otherwise specified, "dereferencing" as it used in the context of Git
> +commands or protocols is implicitly recursive.

Nice to see this spelled out like this.

> @@ -444,6 +461,12 @@ exclude;;
>  	of the logical predecessor(s) in the line of development, i.e. its
>  	parents.
>  
> +[[def_peel]]peel::
> +	Synonym for object <<def_dereference,dereference>>. Most commonly used
> +	in the context of tags, where it refers to the process of recursively
> +	dereferencing a <<def_tag_object,tag object>> until the result object's
> +	<<def_object_type,type>> is something other than "tag".

"object dereference" is not defined anywhere (yet).  "Most commonly
used in the context of tags" implies that objects other than tags
can be "peeled" and "object dereference" is a word to refer to
peeling either "commit" or "tag", but we would want to be a bit more
clear and explicit.  Let's either define "object dereference", or
better yet, avoid saying "object dereference" here and instead say
something like: "Synonym for dereference when used on tags and
commits".

I've never seen "peel" used for commits, though.  So another
improvement might be to say "peel" is "an act of dereferencing a
tag" here.

Thanks.

  reply	other threads:[~2023-11-10  0:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09 23:57 [PATCH] glossary: add definitions for dereference & peel Victoria Dye via GitGitGadget
2023-11-10  0:22 ` Junio C Hamano [this message]
2023-11-10  5:20   ` Junio C Hamano
2023-11-10  8:28 ` Kristoffer Haugsbakk
2023-11-13 23:17 ` [PATCH v2] " Victoria Dye via GitGitGadget
2023-11-14  4:49   ` Junio C Hamano

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=xmqq1qcyxxri.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=ps@pks.im \
    --cc=vdye@github.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;
as well as URLs for NNTP newsgroup(s).