{"thread":{"id":"19326","subject":"check-ref-format question","startedAt":"2009-05-13T00:09:28Z","lastAt":"2009-05-18T02:36:34Z","messageCount":8,"participants":["Geoff Russell","Michael J Gruber","Sverre Rabbelier","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113712","messageId":"93c3eada0905121709k73a47bddu60def6b5fbc1b15e@mail.gmail.com","threadId":"19326","inReplyTo":null,"subject":"check-ref-format question","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2009-05-13T00:09:28Z","receivedAt":"2009-05-13T00:09:28Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"1 $ git --version\ngit version 1.6.2.3\n2 $ git check-ref-format xxxx && echo OK\n3 $ git-check-ref-format --branch xxxx && echo OK\nxxxx\nOK\n4 $ git check-ref-format --branch xxxx && echo OK\nusage: git check-ref-format refname\n\n\n2 seems wrong,\nI tried 3 after looking at  builtin-check-ref-format.c\nI couldn't find any test cases in the git/t directory\n\n>From the documenation, I expect \"git check-ref-format xxx\" to return 0 if xxx is\na valid branch or ref name.  git version 1.6.3 gives the same results.\n\nCheers,\nGeoff.\n"},{"id":"113790","messageId":"4A0AD5A2.2090103@drmicha.warpmail.net","threadId":"19326","inReplyTo":"93c3eada0905121709k73a47bddu60def6b5fbc1b15e@mail.gmail.com","subject":"Re: check-ref-format question","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-13T14:13:54Z","receivedAt":"2009-05-13T14:13:54Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Geoff Russell venit, vidit, dixit 13.05.2009 02:09:\n> 1 $ git --version\n> git version 1.6.2.3\n> 2 $ git check-ref-format xxxx && echo OK\n> 3 $ git-check-ref-format --branch xxxx && echo OK\n> xxxx\n> OK\n> 4 $ git check-ref-format --branch xxxx && echo OK\n> usage: git check-ref-format refname\n> \n> \n> 2 seems wrong,\n> I tried 3 after looking at  builtin-check-ref-format.c\n> I couldn't find any test cases in the git/t directory\n> \n> From the documenation, I expect \"git check-ref-format xxx\" to return 0 if xxx is\n> a valid branch or ref name.  git version 1.6.3 gives the same results.\n\nThere are several things going on:\n\nA) In 3 you use a different git than in 1,2,4. You told us the latter is\n1.6.2.3, and I'm telling you the former contains v1.6.2.1-310-ga31dca0\n(which has the new --branch option).\nThis simply checks whether refs/heads/xxxx is sane. (It also resolves\n@{-1} and such, which is what makes it useful at all.)\n\nB) \"master\" certainly looks like a valid refname, the doc seems to imply\nthat it should pass the check.\n\nC) Looking at the code, check-ref-format checks explicitly for the\npresence of at least 2 levels: foo/bar is good, foo is bad. So, master\nalways had been bad, as well (or bad) as full sha1s!\n\nThe code has always behaved like C since its inception but I don't know\nthe rationale behind the 2 level requirement. Daniel, Junio?\n\nMichael\n"},{"id":"113792","messageId":"fabb9a1e0905130740i56a05eaft3b3b28010d8d385b@mail.gmail.com","threadId":"19326","inReplyTo":"4A0AD5A2.2090103@drmicha.warpmail.net","subject":"Re: check-ref-format question","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-05-13T14:40:28Z","receivedAt":"2009-05-13T14:40:28Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, May 13, 2009 at 16:13, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> The code has always behaved like C since its inception but I don't know\n> the rationale behind the 2 level requirement. Daniel, Junio?\n\nMethinks that since it is a plumbing command it is up to the porcelain\nto translate \"master\" into \"refs/heads/master\" or\n\"refs/remotes/origin/master\" (or whatever is appropriate) before\ndispatching to check-ref-format?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"113794","messageId":"alpine.LNX.2.00.0905131051240.2147@iabervon.org","threadId":"19326","inReplyTo":"4A0AD5A2.2090103@drmicha.warpmail.net","subject":"Re: check-ref-format question","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-05-13T15:03:52Z","receivedAt":"2009-05-13T15:03:52Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 13 May 2009, Michael J Gruber wrote:\n\n> Geoff Russell venit, vidit, dixit 13.05.2009 02:09:\n> > 1 $ git --version\n> > git version 1.6.2.3\n> > 2 $ git check-ref-format xxxx && echo OK\n> > 3 $ git-check-ref-format --branch xxxx && echo OK\n> > xxxx\n> > OK\n> > 4 $ git check-ref-format --branch xxxx && echo OK\n> > usage: git check-ref-format refname\n> > \n> > \n> > 2 seems wrong,\n> > I tried 3 after looking at  builtin-check-ref-format.c\n> > I couldn't find any test cases in the git/t directory\n> > \n> > From the documenation, I expect \"git check-ref-format xxx\" to return 0 if xxx is\n> > a valid branch or ref name.  git version 1.6.3 gives the same results.\n> \n> There are several things going on:\n> \n> A) In 3 you use a different git than in 1,2,4. You told us the latter is\n> 1.6.2.3, and I'm telling you the former contains v1.6.2.1-310-ga31dca0\n> (which has the new --branch option).\n> This simply checks whether refs/heads/xxxx is sane. (It also resolves\n> @{-1} and such, which is what makes it useful at all.)\n> \n> B) \"master\" certainly looks like a valid refname, the doc seems to imply\n> that it should pass the check.\n> \n> C) Looking at the code, check-ref-format checks explicitly for the\n> presence of at least 2 levels: foo/bar is good, foo is bad. So, master\n> always had been bad, as well (or bad) as full sha1s!\n> \n> The code has always behaved like C since its inception but I don't know\n> the rationale behind the 2 level requirement. Daniel, Junio?\n\nIn general, it's because you use it right before trying to use git \nupdate-ref $name, and you probably don't really want to change \nrefs/master. Unless you know exactly what you're going (in which case, \nyou're unlikely to check whether it's okay), you want to have a first \nlevel that specifies the type of ref and one or more additional levels \nthat specify which ref of that type it is.\n\nI believe that, if you've got \"master\", and you want to do the sensible \nthing with it (i.e., the file you care about is .git/refs/heads/master), \nyou want to use rev-parse with some option or other, not check-ref-format, \nbut I don't know the plumbing-level shell API very well.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"113797","messageId":"1242229386-27486-1-git-send-email-git@drmicha.warpmail.net","threadId":"19326","inReplyTo":"alpine.LNX.2.00.0905131051240.2147@iabervon.org","subject":"[PATCH] Documentation: clarify / requirement in 'git check-ref-format'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-13T15:43:06Z","receivedAt":"2009-05-13T15:43:06Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"'git check-ref-format' checks for the presence of at least one '/', the\nidea being that there should be no refs directly below 'refs/', so there\nshould be a category like 'heads/' or 'tags/' in a refname.\n\nTry and make this clearer in the man page.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\nDaniel Barkalow venit, vidit, dixit 13.05.2009 17:03:\n> On Wed, 13 May 2009, Michael J Gruber wrote:\n> \n>> Geoff Russell venit, vidit, dixit 13.05.2009 02:09:\n>>> 1 $ git --version\n>>> git version 1.6.2.3\n>>> 2 $ git check-ref-format xxxx && echo OK\n>>> 3 $ git-check-ref-format --branch xxxx && echo OK\n>>> xxxx\n>>> OK\n>>> 4 $ git check-ref-format --branch xxxx && echo OK\n>>> usage: git check-ref-format refname\n>>>\n>>>\n>>> 2 seems wrong,\n>>> I tried 3 after looking at  builtin-check-ref-format.c\n>>> I couldn't find any test cases in the git/t directory\n>>>\n>>> From the documenation, I expect \"git check-ref-format xxx\" to return 0 if xxx is\n>>> a valid branch or ref name.  git version 1.6.3 gives the same results.\n>>\n>> There are several things going on:\n>>\n>> A) In 3 you use a different git than in 1,2,4. You told us the latter is\n>> 1.6.2.3, and I'm telling you the former contains v1.6.2.1-310-ga31dca0\n>> (which has the new --branch option).\n>> This simply checks whether refs/heads/xxxx is sane. (It also resolves\n>> @{-1} and such, which is what makes it useful at all.)\n>>\n>> B) \"master\" certainly looks like a valid refname, the doc seems to imply\n>> that it should pass the check.\n>>\n>> C) Looking at the code, check-ref-format checks explicitly for the\n>> presence of at least 2 levels: foo/bar is good, foo is bad. So, master\n>> always had been bad, as well (or bad) as full sha1s!\n>>\n>> The code has always behaved like C since its inception but I don't know\n>> the rationale behind the 2 level requirement. Daniel, Junio?\n> \n> In general, it's because you use it right before trying to use git \n> update-ref $name, and you probably don't really want to change \n> refs/master. Unless you know exactly what you're going (in which case, \n> you're unlikely to check whether it's okay), you want to have a first \n> level that specifies the type of ref and one or more additional levels \n> that specify which ref of that type it is.\n> \n> I believe that, if you've got \"master\", and you want to do the sensible \n> thing with it (i.e., the file you care about is .git/refs/heads/master), \n> you want to use rev-parse with some option or other, not check-ref-format, \n> but I don't know the plumbing-level shell API very well.\n> \n> \t-Daniel\n> *This .sig left intentionally blank*\n\nThanks Daniel and Sverre for the clarification, this makes a lot of sense.\n\nMichael\n\n Documentation/git-check-ref-format.txt |    4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt\nindex bf43454..0b7982e 100644\n--- a/Documentation/git-check-ref-format.txt\n+++ b/Documentation/git-check-ref-format.txt\n@@ -25,6 +25,10 @@ imposes the following rules on how references are named:\n   grouping, but no slash-separated component can begin with a\n   dot `.`.\n \n+. They must contain at least one `/`. This enforces the presence of a\n+  category like `heads/`, `tags/` etc. but the actual names are not\n+  restricted.\n+\n . They cannot have two consecutive dots `..` anywhere.\n \n . They cannot have ASCII control characters (i.e. bytes whose\n-- \n1.6.3.195.gad816\n"},{"id":"113858","messageId":"93c3eada0905131726p3afe8e68j160bd3931886093d@mail.gmail.com","threadId":"19326","inReplyTo":"4A0AD5A2.2090103@drmicha.warpmail.net","subject":"Re: check-ref-format question","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2009-05-14T00:26:39Z","receivedAt":"2009-05-14T00:26:39Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"On Wed, May 13, 2009 at 11:43 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Geoff Russell venit, vidit, dixit 13.05.2009 02:09:\n>> 1 $ git --version\n>> git version 1.6.2.3\n>> 2 $ git check-ref-format xxxx && echo OK\n>> 3 $ git-check-ref-format --branch xxxx && echo OK\n>> xxxx\n>> OK\n>> 4 $ git check-ref-format --branch xxxx && echo OK\n>> usage: git check-ref-format refname\n>>\n>>\n>> 2 seems wrong,\n>> I tried 3 after looking at  builtin-check-ref-format.c\n>> I couldn't find any test cases in the git/t directory\n>>\n>> From the documenation, I expect \"git check-ref-format xxx\" to return 0 if xxx is\n>> a valid branch or ref name.  git version 1.6.3 gives the same results.\n>\n> There are several things going on:\n>\n> A) In 3 you use a different git than in 1,2,4. You told us the latter is\n> 1.6.2.3, and I'm telling you the former contains v1.6.2.1-310-ga31dca0\n> (which has the new --branch option).\n> This simply checks whether refs/heads/xxxx is sane. (It also resolves\n> @{-1} and such, which is what makes it useful at all.)\n\nSorry, my mistake I was running in 2 windows on 2 machine and got\nconfused. Ignore\nline 3 in my example.\n\n>\n> B) \"master\" certainly looks like a valid refname, the doc seems to imply\n> that it should pass the check.\n\n$ git --version\ngit version 1.6.2.3\n$ git check-ref-format xxxx && echo OK\n$ git check-ref-format master && echo OK\n$ git check-ref-format master/xxxx && echo OK\nOK\n\nI'm confused.\n\nGeoff.\n\n\n>\n> C) Looking at the code, check-ref-format checks explicitly for the\n> presence of at least 2 levels: foo/bar is good, foo is bad. So, master\n> always had been bad, as well (or bad) as full sha1s!\n>\n> The code has always behaved like C since its inception but I don't know\n> the rationale behind the 2 level requirement. Daniel, Junio?\n>\n> Michael\n>\n"},{"id":"113898","messageId":"4A0BC717.1060900@drmicha.warpmail.net","threadId":"19326","inReplyTo":"93c3eada0905131726p3afe8e68j160bd3931886093d@mail.gmail.com","subject":"Re: check-ref-format question","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-14T07:24:07Z","receivedAt":"2009-05-14T07:24:07Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Geoff Russell venit, vidit, dixit 14.05.2009 02:26:\n> On Wed, May 13, 2009 at 11:43 PM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Geoff Russell venit, vidit, dixit 13.05.2009 02:09:\n>>> 1 $ git --version\n>>> git version 1.6.2.3\n>>> 2 $ git check-ref-format xxxx && echo OK\n>>> 3 $ git-check-ref-format --branch xxxx && echo OK\n>>> xxxx\n>>> OK\n>>> 4 $ git check-ref-format --branch xxxx && echo OK\n>>> usage: git check-ref-format refname\n>>>\n>>>\n>>> 2 seems wrong,\n>>> I tried 3 after looking at  builtin-check-ref-format.c\n>>> I couldn't find any test cases in the git/t directory\n>>>\n>>> From the documenation, I expect \"git check-ref-format xxx\" to return 0 if xxx is\n>>> a valid branch or ref name.  git version 1.6.3 gives the same results.\n>>\n>> There are several things going on:\n>>\n>> A) In 3 you use a different git than in 1,2,4. You told us the latter is\n>> 1.6.2.3, and I'm telling you the former contains v1.6.2.1-310-ga31dca0\n>> (which has the new --branch option).\n>> This simply checks whether refs/heads/xxxx is sane. (It also resolves\n>> @{-1} and such, which is what makes it useful at all.)\n> \n> Sorry, my mistake I was running in 2 windows on 2 machine and got\n> confused. Ignore\n> line 3 in my example.\n> \n>>\n>> B) \"master\" certainly looks like a valid refname, the doc seems to imply\n>> that it should pass the check.\n> \n> $ git --version\n> git version 1.6.2.3\n> $ git check-ref-format xxxx && echo OK\n> $ git check-ref-format master && echo OK\n> $ git check-ref-format master/xxxx && echo OK\n> OK\n> \n> I'm confused.\n> \n> Geoff.\n\nPlease read on to my item C), and check the documentation patch which I\nsubmitted. If you're still confused after that I need to revise my patch ;)\n\n> \n> \n>>\n>> C) Looking at the code, check-ref-format checks explicitly for the\n>> presence of at least 2 levels: foo/bar is good, foo is bad. So, master\n>> always had been bad, as well (or bad) as full sha1s!\n>>\n>> The code has always behaved like C since its inception but I don't know\n>> the rationale behind the 2 level requirement. Daniel, Junio?\n>>\n>> Michael\n>>\n"},{"id":"114149","messageId":"93c3eada0905171936u2e6d67d5mc7eb80936b710a6b@mail.gmail.com","threadId":"19326","inReplyTo":"1242229386-27486-1-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH] Documentation: clarify / requirement in 'git check-ref-format'","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2009-05-18T02:36:34Z","receivedAt":"2009-05-18T02:36:34Z","isPatch":true,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"On Thu, May 14, 2009 at 1:13 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> 'git check-ref-format' checks for the presence of at least one '/', the\n> idea being that there should be no refs directly below 'refs/', so there\n> should be a category like 'heads/' or 'tags/' in a refname.\n>\n> Try and make this clearer in the man page.\n>\n> [....snip]\n> +. They must contain at least one `/`. This enforces the presence of a\n> +  category like `heads/`, `tags/` etc. but the actual names are not\n> +  restricted.\n> +\n>  . They cannot have two consecutive dots `..` anywhere.\n>\n> [ ...snip]\n\nAh, okay. This is clear. Many thanks.\n\nCheers,\nGeoff\n"}]}