Subject: Re: [PATCH 0/9] for-each-ref optimizations & usability improvements

From: Patrick Steinhardt <[email-masked]>
Date: Tue, 7 Nov 2023 11:49:34 +0100

On Mon, Nov 06, 2023 at 06:48:29PM -0800, Victoria Dye wrote:
> Junio C Hamano wrote:
> > "Victoria Dye via GitGitGadget" <[email-masked]> writes:
[snip]
> >>  * I'm not attached to '--full-deref' as a name - if someone has an idea for
> >>    a more descriptive name, please suggest it!
> > 
> > Another candidate verb may be "to peel", and I have no strong
> > opinion between it and "to dereference".  But I have a mild aversion
> > to an abbreviation that is not strongly established.
> > 
> 
> Makes sense. I got the "deref" abbreviation for 'update-ref --no-deref', but
> 'show-ref' has a "--dereference" option and protocol v2's "ls-refs" includes
> a "peel" arg. "Dereference" is the term already used in the 'for-each-ref'
> documentation, though, so if no one comes in with an especially strong
> opinion on this I'll change the option to '--full-dereference'. Thanks!

But doesn't dereferencing in the context of git-update-ref(1) refer to
something different? It's not about tags, but it is about symbolic
references and whether we want to update the symref or the pointee. But
true enough, in git-show-ref(1) "dereference" actually means that we
should peel the tag.

To me it feels like preexisting commands are confused already. In my
mind model:

    - "peel" means that an object gets resolved to one of its pointees.
      This also includes the case here, where a tag gets peeled to its
      pointee.

    - "dereference" means that a symbolic reference gets resolved to its
      pointee. This matches what we do in `git update-ref --no-deref`.

But after reading through the code I don't think we distinguish those
terms cleanly throughout our codebase. Still, "peeling" feels like a
better match in my opinion.

Patrick