Patrick Steinhardt wrote: > 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. Since both annotated tags and symbolic refs are essentially pointers, it's not surprising that they both use the term "dereference." Even though "deref" refers to symbolic refs in 'update-ref', its existence as an abbreviation for "dereference" is relevant when coming up with a way to abbreviate "dereference" when referring to tags. > > 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. Hmm. I think I mostly agree on your definition of "peel". In the docs, it's used to refer to: - recursively resolving an OID to an object of a specified type [1] - recursively resolving a tag OID to a non-tag object [2] Notably, there seems to be a strong association of "peeling" to "recursive resolution". Which means it doesn't necessarily describe what "*" currently does. "Dereference" generally seems like a looser term than what you've suggested. It does refer to symbolic ref resolution as you describe [3], but "recursive dereference" is definitely also a synonym for "peel" [4]. That, combined with the fact that "*" is the "dereference operator", leads me to believe that "%(*fieldname)" would accurately be described as a "tag dereference" field in the context of 'for-each-ref'. As I mentioned in [5], I'm going to try adding this functionality with a field specifier rather than a command line option, so the name of the option might be moot. But, since dereferencing/peeling will still be relevant to the changes, I'll make sure the terminology I use in the documentation is as precise as possible (i.e., use "peel" where I previously used "fully dereference"). Separately, this has inspired me to revisit something I've been putting off, which is to add a definition for "peel" (and now probably "dereference" as well) in 'gitglossary'. I'll try to send that out in the next couple days. Thanks! [1] https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt---verify [2] https://git-scm.com/docs/gitprotocol-v2#_ls_refs [3] https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefsymrefasymref [4] https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefcommit-ishacommit-ishalsocommittish [5] https://lore.kernel.org/git/cf691b7c-288f-4cc9-a2ac-1a43972ae446@xxxxxxxxxx/ > > Patrick
