patchgit-tag(1): Refer to git-check-ref-format(1) for <name>

Explain briefly what characters are prohibited in tag <name>
and point to git-check-ref-format(1) manual page for
more information.
---
 Documentation/git-tag.txt |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Jari Aalto <jari.aalto@cante.net> writes:

Thanks.

I do not see a reason to reject this patch (other than lack of sign-off), but at the same time, I wish if we can somehow teach people that the branches and the tags are just two special cases of refs that follow exactly the same set of rules, we would not have to apply another similar patch to git-branch documentation and instead we can teach what the naming rules are for refs in general. Then the readers can learn the rule once, and extend the knowledge to other types of refs (e.g. notes) in the future.

I however do not think of a way to organize our documentations without too many levels of indirections (e.g. repeating "X is just a ref and for naming rules, see check-ref-format(1)" for all types X of refs). Not repeating the rules for documentation of each kind of ref will make the maintenance a lot easier but hurts readability, but the set of rules is not a large enough to justify the complexity to use a separate include file at the source level.

Explain briefly what characters are prohibited in tag <name> and point to git-check-ref-format(1) manual page for further information.

Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
 Documentation/git-tag.txt |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Quoting Junio C Hamano <gitster@pobox.com>

  but at the same time, I wish if we can somehow teach people that the
  branches and the tags are just two special cases of refs that follow
  exactly the same set of rules, we would not have to apply another
  similar patch to git-branch documentation and instead we can teach what
  the naming rules are for refs in general.  Then the readers can learn
  the rule once, and extend the knowledge to other types of refs
  (e.g. notes) in the future.

I read the help page for the git-branch command and noticed that we don't need a similar patch. I think the git-branch help is nicer than git-tag help because it doesn't reproduce the rule in an incomplete way that can lead to confusion, divergence, and additional maintenance hassle.

-- 8< -- 8< -- 8< -- cut here >8 -- >8 -- >8 --

Subject: Documentation: consistently refer to check-ref-format

Change the <name> placeholder to <tagname> in the SYNOPSIS section of git-tag documentation, and describe it in the OPTIONS section in a way similar to how documentation for git-branch does.

Add SEE ALSO section to list the other documentation pages these two pages refer to.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---

 Documentation/git-branch.txt |    6 ++++++
 Documentation/git-tag.txt    |   20 ++++++++++++++------
 2 files changed, 20 insertions(+), 6 deletions(-)

Quoting myself...

Should I further polish this patch?

Nanako Shiraishi <nanako3@lavabit.com> writes:

No, it just fell through the cracks of my mailbox. I tend to agree that it is better to mention only the presense of rules, and refer to the rules described in the definitive document.

Safe names are designed to be what most sane people would naturally choose to use anyway and they would not need to see the clutter that describes only the half of the rules there. And more importantly, the people who do get errors by choosing illegal names by accident would _want_ to see the full set of rules before choosing another name to avoid getting the same error again.

Spelling only the half of the rules in the tag/branch manual page would not help neither audience.