{"thread":{"id":"9650","subject":"[PATCH] Improve error message: not a valid branch name","startedAt":"2007-08-26T15:28:18Z","lastAt":"2007-08-26T22:25:00Z","messageCount":4,"participants":["Jari Aalto","Junio C Hamano","J. Bruce Fields"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"51560","messageId":"y7fyfh7x.fsf@cante.net","threadId":"9650","inReplyTo":null,"subject":"[PATCH] Improve error message: not a valid branch name","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-08-26T15:28:18Z","receivedAt":"2007-08-26T15:28:18Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"\n(create_branch): Extend die message from 'is not a valid branch name'\nto '...(see git-check-ref-format)'.\n\nSigned-off-by: Jari Aalto <jari.aalto@cante.net>\n---\n builtin-branch.c |    9 ++++++---\n 1 files changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-branch.c b/builtin-branch.c\nindex 7408285..1006a85 100644\n--- a/builtin-branch.c\n+++ b/builtin-branch.c\n@@ -431,7 +431,8 @@ static void create_branch(const char *name, const char *start_name,\n \n \tsnprintf(ref, sizeof ref, \"refs/heads/%s\", name);\n \tif (check_ref_format(ref))\n-\t\tdie(\"'%s' is not a valid branch name.\", name);\n+\t\tdie(\"'%s' is not a valid branch name \"\n+                    \"(see git-check-ref-format)\", name);\n \n \tif (resolve_ref(ref, sha1, 1, NULL)) {\n \t\tif (!force)\n@@ -502,13 +503,15 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t\tdie(\"Old branchname too long\");\n \n \tif (check_ref_format(oldref))\n-\t\tdie(\"Invalid branch name: %s\", oldref);\n+\t\tdie(\"Invalid branch name: %s \"\n+                    \"(see git-check-ref-format)\", oldref);\n \n \tif (snprintf(newref, sizeof(newref), \"refs/heads/%s\", newname) > sizeof(newref))\n \t\tdie(\"New branchname too long\");\n \n \tif (check_ref_format(newref))\n-\t\tdie(\"Invalid branch name: %s\", newref);\n+\t\tdie(\"Invalid branch name: %s \"\n+                    \"(see git-check-ref-format)\", newref);\n \n \tif (resolve_ref(newref, sha1, 1, NULL) && !force)\n \t\tdie(\"A branch named '%s' already exists.\", newname);\n-- \n1.5.3.rc5\n"},{"id":"51609","messageId":"7vd4xang1n.fsf@gitster.siamese.dyndns.org","threadId":"9650","inReplyTo":"y7fyfh7x.fsf@cante.net","subject":"Re: [PATCH] Improve error message: not a valid branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-26T21:26:28Z","receivedAt":"2007-08-26T21:26:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jari Aalto <jari.aalto@cante.net> writes:\n\n> (create_branch): Extend die message from 'is not a valid branch name'\n> to '...(see git-check-ref-format)'.\n\nI think you meant to say \"see git-check-ref-format(1)\" as you\nmeant the manual page.\n\nI am a bit torn on this.  git-check-ref-format.1 is where we\ncurrently _happen_ to describe what valid refnames should look\nlike, but it could be argued that it is a bug in the manual.\n\nTwo possible improvements that are mutually incompatible would\nbe:\n\n - refactor that part of the manual to be included in the pages\n   for any and all commands that can take refname from the user;\n   this is inpractical as almost all command would be affected.\n\n - move that to more central place, say git(7), and everybody\n   refer to that page;\n\nI'd personally prefer the latter, as \"naming things\" is such a\ncentral thing for the use of the system (this applies to the\ndescription of \"SHA-1 expression\" that we curently have in\ngit-rev-parse(1) as well) and it is better for users to have\nunderstanding of such fundamental syntaxes and concepts before\neven using any individual commands.\n"},{"id":"51610","messageId":"ejhqeynj.fsf@cante.net","threadId":"9650","inReplyTo":"7vd4xang1n.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Improve error message: not a valid branch name","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-08-26T22:09:20Z","receivedAt":"2007-08-26T22:09:20Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jari Aalto <jari.aalto@cante.net> writes:\n>\n>> (create_branch): Extend die message from 'is not a valid branch name'\n>> to '...(see git-check-ref-format)'.\n>\n> I think you meant to say \"see git-check-ref-format(1)\" as you\n> meant the manual page.\n\nYes.\n\n> I am a bit torn on this.  git-check-ref-format.1 is where we\n> currently _happen_ to describe what valid refnames should look\n> like, but it could be argued that it is a bug in the manual.\n>\n> Two possible improvements that are mutually incompatible would\n> be:\n>\n>  - refactor that part of the manual to be included in the pages\n>    for any and all commands that can take refname from the user;\n>    this is inpractical as almost all command would be affected.\n>\n>  - move that to more central place, say git(7), and everybody\n>    refer to that page;\n>\n> I'd personally prefer the latter, as \"naming things\" is such a\n> central thing for the use of the system (this applies to the\n> description of \"SHA-1 expression\" that we curently have in\n> git-rev-parse(1) as well) and it is better for users to have\n> understanding of such fundamental syntaxes and concepts before\n> even using any individual commands.\n\nWholeheartedly concur.\n\nShould I re-submit the patch to refer to git(7) instead?\n\nJari\n"},{"id":"51611","messageId":"20070826222500.GA9116@fieldses.org","threadId":"9650","inReplyTo":"ejhqeynj.fsf@cante.net","subject":"Re: [PATCH] Improve error message: not a valid branch name","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-08-26T22:25:00Z","receivedAt":"2007-08-26T22:25:00Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Aug 27, 2007 at 01:09:20AM +0300, Jari Aalto wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n> > Two possible improvements that are mutually incompatible would\n> > be:\n> >\n> >  - refactor that part of the manual to be included in the pages\n> >    for any and all commands that can take refname from the user;\n> >    this is inpractical as almost all command would be affected.\n> >\n> >  - move that to more central place, say git(7), and everybody\n> >    refer to that page;\n> >\n> > I'd personally prefer the latter, as \"naming things\" is such a\n> > central thing for the use of the system (this applies to the\n> > description of \"SHA-1 expression\" that we curently have in\n> > git-rev-parse(1) as well) and it is better for users to have\n> > understanding of such fundamental syntaxes and concepts before\n> > even using any individual commands.\n> \n> Wholeheartedly concur.\n\nSounds good to me too, but...\n\n> Should I re-submit the patch to refer to git(7) instead?\n\n... git(7) is pretty long, so finding the referred-to information in\nthat man page might take a while.  Would it be possible to put this in a\n(section 7?) man page of its own?\n\n--b.\n"}]}