"Sean Allred via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> +OUTPUT
> +------
> +
> +The output is in the format:
> +
> +------------
> +<OID> TAB <reference name> LF
> +------------
It seems that
$ git grep -i '<OID>' Documentation/
everybody spell the object identifer as "<oid>" in lowercase. TAB
and LF are better left uppercase.
$ git grep -i '<ref' Documentation/
says that we never say <reference name>. Almost everybody would say
<ref> here (and that curiously is what glossary-content.txt has---it
feels a bit funny to have "ref" not "reference" there, as the former
looks as if it were an informal abbreviation of the latter, but
'ref' seems to be the offical name of that thing).
The documentation for "show-branch" uses many <reference>s in the
description, which should be updated to match what its SYNOPSIS
section uses, which is <ref>.
> +For example,
> +
> +----
> +$ git ls-remote
> +950264636c68591989456e3ba0a5442f93152c1a refs/heads/main
> +73876f4861cd3d187a4682290ab75c9dccadbc56 refs/heads/maint
> +d9ab777d41f92a8c1684c91cfb02053d7dd1046b refs/heads/next
> +74a0ffe000da036ce4ca843d991a7c6b8c246a08 refs/heads/seen
> +860bc4360c4fcba0fe2df942984d87f8467af3df refs/heads/todo
> +d4ca2e3147b409459955613c152220f4db848ee1 refs/tags/v2.40.0
> +8810a79228a149a9773bf9c75f381fca27a6a80e refs/tags/v2.40.0-rc0
> +f899c182d0bffb6e915da7c8db9be202b144c098 refs/tags/v2.40.0-rc1
> +6bed3304b2b2f1cf440ca3050b57a7cf3a3fe687 refs/tags/v2.40.0-rc2
> +----
Do we really need 9 lines of output to help readers understand the
output? I somehow feel that it would not add any clarity for the
readers to add more, when we already have 2 of the same kind in the
list, and it smells even more excessive to give more than 3 of the
same kind.
Oh, isn't it even worse? I see an EXAMPLE section that gives a
similar looking output. Do we need to add one more in a separate
section?
What is curious about your "example" is that usually the first entry
we see in the "ls-remote" output is for HEAD. Another curiousity
that is shared between yours and the existing examples is that
annotated tags should show their peeled representation, but the
examples are not showing (I suspect that existing ones were
documented way before we show peeled tags). For reference, the
output of running the command against my kernel.org repository
starts like so:
$ git ls-remote ko
27d43aaaf50ef0ae014b88bba294f93658016a2e HEAD
27d43aaaf50ef0ae014b88bba294f93658016a2e refs/heads/main
73876f4861cd3d187a4682290ab75c9dccadbc56 refs/heads/maint
27d43aaaf50ef0ae014b88bba294f93658016a2e refs/heads/master
c903bb7e22f8f86da64de537e5768ab0ca886f4b refs/heads/next
29b7b507b4e8ff04bf912512bb466ea39805b9e5 refs/heads/seen
860bc4360c4fcba0fe2df942984d87f8467af3df refs/heads/todo
d5aef6e4d58cfe1549adef5b436f3ace984e8c86 refs/tags/gitgui-0.10.0
3d654be48f65545c4d3e35f5d3bbed5489820930 refs/tags/gitgui-0.10.0^{}
33682a5e98adfd8ba4ce0e21363c443bd273eb77 refs/tags/gitgui-0.10.1
729ffa50f75a025935623bfc58d0932c65f7de2f refs/tags/gitgui-0.10.1^{}
...
So,
* correct <OID> and <reference name> in the format description.
* describe that <ref> in the output may be followed by ^{} to
show peeled representation of the preceding tag.
* update existing examples to show peeled tags.
are what I found missing in this patch.
Thanks for working on improving this documentation page.
