On Mon, Nov 06, 2023 at 06:48:29PM -0800, Victoria Dye wrote:
> Junio C Hamano wrote:
> > "Victoria Dye via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
