{"thread":{"id":"25685","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","startedAt":"2010-11-09T07:30:23Z","lastAt":"2010-12-10T01:35:20Z","messageCount":21,"participants":["Yann Dirson","Kevin Ballard","Jeff King","Junio C Hamano","Jakub Narebski","Nguyễn Thái Ngọc Duy","Matthieu Moy","Jonathan Nieder","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"155462","messageId":"20101109083023.783fad9b@chalon.bertin.fr","threadId":"25685","inReplyTo":null,"subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2010-11-09T07:30:23Z","receivedAt":"2010-11-09T07:30:23Z","isPatch":false,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"Jeff wrote:\n> It seems to me the natural way to do that would be to use our existing\n> generic \"start at this ref and follow some chain\" syntax, which is\n> ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}.\n\nWe may want to keep the \"/\" mnemonic (which seems no to conflict\nwithcurrent use either), rather than the \":\" part, with something like\norigin/pu^{/Merge 'kb/blame-author-email'}, and keep \":\" for future use.\n\n> We also have ref@{upstream}. The analogue here would be\n> origin/pu@{:Merge 'kb/blame-author-email'}.\n\nThat's somewhat different, it looks like the foo@{...} only applies to\nreferences with name \"foo\", and not to arbitrary revisions. Allowing a\nsearch to start from any commit seems more useful here.\n\nKevin wrote:\n> Junio wrote:\n> > $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2'\n[...]\n>\n> Interesting idea. It certainly solves the problem of being able to\n> embed it within other operations (though you do then have to worry\n> about escaping any embedded close-parens in the search), though it\n> does mean my suggestion for being able to select the 2nd (or nth)\n> match won't work.\n\nSyntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be\nsomewhat consistent with the commit^2 case, and would seem unambiguous\nas well - a bit weird, though.\n\n-- \nYann Dirson - Bertin Technologies\n"},{"id":"155465","messageId":"13A8F1B3-39B0-4D11-8763-9C458F75487D@sb.org","threadId":"25685","inReplyTo":"20101109083023.783fad9b@chalon.bertin.fr","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-11-09T08:06:47Z","receivedAt":"2010-11-09T08:06:47Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Nov 8, 2010, at 11:30 PM, Yann Dirson wrote:\n\n> Kevin wrote:\n>> Junio wrote:\n>>> $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2'\n> [...]\n>> \n>> Interesting idea. It certainly solves the problem of being able to\n>> embed it within other operations (though you do then have to worry\n>> about escaping any embedded close-parens in the search), though it\n>> does mean my suggestion for being able to select the 2nd (or nth)\n>> match won't work.\n> \n> Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be\n> somewhat consistent with the commit^2 case, and would seem unambiguous\n> as well - a bit weird, though.\n\nThis violates the idea that once you reach the end of a ^{} structure,\nit resolves to a commit that can then be modified by subsequent operations.\n\n-Kevin Ballard\n"},{"id":"155467","messageId":"20101109102428.5ba8dc13@chalon.bertin.fr","threadId":"25685","inReplyTo":"13A8F1B3-39B0-4D11-8763-9C458F75487D@sb.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2010-11-09T09:24:28Z","receivedAt":"2010-11-09T09:24:28Z","isPatch":false,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"On Tue, 09 Nov 2010 00:06:47 -0800\nKevin Ballard wrote:\n\n> On Nov 8, 2010, at 11:30 PM, Yann Dirson wrote:\n> \n> > Kevin wrote:\n> >> Junio wrote:\n> >>> $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2'\n> > [...]\n> >> \n> >> Interesting idea. It certainly solves the problem of being able to\n> >> embed it within other operations (though you do then have to worry\n> >> about escaping any embedded close-parens in the search), though it\n> >> does mean my suggestion for being able to select the 2nd (or nth)\n> >> match won't work.\n> > \n> > Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be\n> > somewhat consistent with the commit^2 case, and would seem\n> > unambiguous as well - a bit weird, though.\n> \n> This violates the idea that once you reach the end of a ^{} structure,\n> it resolves to a commit that can then be modified by subsequent\n> operations.\n\nOK, that's kinda related to the \"looks weird\" issue. \n\nAnother idea: origin/pu^{:2/Merge 'kb/blame-author-email'}\nSince the foo^{objecttype} syntax would not care for a count, it is not\na problem, and it keeps provision for using a count with future\noperators. OTOH, it could be a problem if we extend foo^{bar} to\naccept \"bar\" for other things than object types.\n\n-- \nYann Dirson - Bertin Technologies\n"},{"id":"155498","messageId":"20101109161015.GB24975@sigill.intra.peff.net","threadId":"25685","inReplyTo":"20101109083023.783fad9b@chalon.bertin.fr","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-11-09T16:10:18Z","receivedAt":"2010-11-09T16:10:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 09, 2010 at 08:30:23AM +0100, Yann Dirson wrote:\n\n> Jeff wrote:\n> > It seems to me the natural way to do that would be to use our existing\n> > generic \"start at this ref and follow some chain\" syntax, which is\n> > ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}.\n> \n> We may want to keep the \"/\" mnemonic (which seems no to conflict\n> withcurrent use either), rather than the \":\" part, with something like\n> origin/pu^{/Merge 'kb/blame-author-email'}, and keep \":\" for future use.\n\nYeah, sorry, the ':' thing was just a think-o on my part. It should\ndefinitely be \"/\".\n\n> > We also have ref@{upstream}. The analogue here would be\n> > origin/pu@{:Merge 'kb/blame-author-email'}.\n> \n> That's somewhat different, it looks like the foo@{...} only applies to\n> references with name \"foo\", and not to arbitrary revisions. Allowing a\n> search to start from any commit seems more useful here.\n\nYeah, agreed.\n\n-Peff\n"},{"id":"155552","messageId":"7vlj52jakh.fsf@alter.siamese.dyndns.org","threadId":"25685","inReplyTo":"20101109102428.5ba8dc13@chalon.bertin.fr","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-10T00:18:06Z","receivedAt":"2010-11-10T00:18:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yann Dirson writes:\n\n>> > Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be\n> ...\n> Another idea: origin/pu^{:2/Merge 'kb/blame-author-email'}\n\nWhat are these \"2\"s?\n\nYou need to question how you figured out the commit you want is the second\none reachable (in whatever traversal order) from something in the first\nplace. Didn't you use \"git log --oneline\" or something to find that out?\nAt that point, you have the object name already, so I doubt such a\n\"counting\" feature is of much practical use.\n"},{"id":"155556","messageId":"050F42EE-34FE-499F-B632-471597EB4881@sb.org","threadId":"25685","inReplyTo":"7vlj52jakh.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-11-10T00:33:31Z","receivedAt":"2010-11-10T00:33:31Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Nov 9, 2010, at 4:18 PM, Junio C Hamano wrote:\n\n> Yann Dirson writes:\n> \n>>>> Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be\n>> ...\n>> Another idea: origin/pu^{:2/Merge 'kb/blame-author-email'}\n> \n> What are these \"2\"s?\n> \n> You need to question how you figured out the commit you want is the second\n> one reachable (in whatever traversal order) from something in the first\n> place. Didn't you use \"git log --oneline\" or something to find that out?\n> At that point, you have the object name already, so I doubt such a\n> \"counting\" feature is of much practical use.\n\nThe particular case that prompted this for me was I knew I had created two\ncommits called \"WIP\", scheduled for renaming later, and I wanted to quickly\nlook at the contents of the first one. I would have loved to be able to\ntype something like `git show :/WIP/2`. I suppose this situation may be rare\nenough not to bother supporting it in the new syntax. With the new syntax\nit will be possible to do something like `git show HEAD^{:/WIP}^^{:/WIP}`, but\nthat looks awfully awkward.\n\nAnother thing to consider - the current :/foo syntax searches for the newest\ncommit reachable from any ref. Using the ^{} syntax will require specifying\na ref first. I'm not sure this is a problem though, as I'm not really sure why\n:/foo searches from all refs to begin with.\n\n-Kevin Ballard"},{"id":"155574","messageId":"20101110083209.6a1252ef@chalon.bertin.fr","threadId":"25685","inReplyTo":"050F42EE-34FE-499F-B632-471597EB4881@sb.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2010-11-10T07:32:09Z","receivedAt":"2010-11-10T07:32:09Z","isPatch":false,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"On Tue, 09 Nov 2010 16:33:31 -0800\nKevin Ballard wrote:\n\n> On Nov 9, 2010, at 4:18 PM, Junio C Hamano wrote:\n> \n> > Yann Dirson writes:\n> > \n> >>>> Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be\n> >> ...\n> >> Another idea: origin/pu^{:2/Merge 'kb/blame-author-email'}\n> > \n> > What are these \"2\"s?\n> > \n> > You need to question how you figured out the commit you want is the\n> > second one reachable (in whatever traversal order) from something\n> > in the first place. Didn't you use \"git log --oneline\" or\n> > something to find that out? At that point, you have the object name\n> > already, so I doubt such a \"counting\" feature is of much practical\n> > use.\n\nI usually always have a gitk displaying history. Whereas it shows the\ncommit summary, it does not show the sha1 for each commit - and even if\nit did, my brain is still more comfortable dealing with words than\nhashes (though that may arguably be an effect of aging ;)\n\n> The particular case that prompted this for me was I knew I had\n> created two commits called \"WIP\", scheduled for renaming later, and I\n> wanted to quickly look at the contents of the first one. I would have\n> loved to be able to type something like `git show :/WIP/2`. I suppose\n> this situation may be rare enough not to bother supporting it in the\n> new syntax. With the new syntax it will be possible to do something\n> like `git show HEAD^{:/WIP}^^{:/WIP}`, but that looks awfully awkward.\n\nAnother use for counting would be for reflog, to lookup things like\n\"2nd to last of yesterday's commits\" - that could be spelled like\n\"master^{:2:yesterday}\" or similar. Not sure it's worth it (I hardly\nuse the @{anything vague} syntax myself, especially because it is so\nvague), but that looked similar enough to be mentionned here.\n\n> Another thing to consider - the current :/foo syntax searches for the\n> newest commit reachable from any ref. Using the ^{} syntax will\n> require specifying a ref first. I'm not sure this is a problem\n> though, as I'm not really sure why :/foo searches from all refs to\n> begin with.\n\nThe syntax could be extended so that ^{whatever} starts looking at\ncurrent commit (ie. HEAD), somewhat like @{whatever} looks at reflog for\ncurrent branch.\n\n-- \nYann Dirson - Bertin Technologies\n"},{"id":"155577","messageId":"20101110084609.78f532a5@chalon.bertin.fr","threadId":"25685","inReplyTo":"23523534-F7A7-4D61-A899-8B3B28566EA7@sb.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2010-11-10T07:46:09Z","receivedAt":"2010-11-10T07:46:09Z","isPatch":false,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"On Tue, 09 Nov 2010 23:46:59 -0800\nKevin Ballard wrote:\n\n> On Nov 9, 2010, at 11:32 PM, Yann Dirson wrote:\n> \n> >> Another thing to consider - the current :/foo syntax searches for\n> >> the newest commit reachable from any ref. Using the ^{} syntax will\n> >> require specifying a ref first. I'm not sure this is a problem\n> >> though, as I'm not really sure why :/foo searches from all refs to\n> >> begin with.\n> > \n> > The syntax could be extended so that ^{whatever} starts looking at\n> > current commit (ie. HEAD), somewhat like @{whatever} looks at\n> > reflog for current branch.\n> \n> :/foo doesn't start from the current commit - it searches all refs.\n> However, making ^{} search all refs if not given one doesn't make\n> sense for any operator except :/foo, so I don't think it's worth doing\n\nYes, that's why I suggested to make it search from HEAD, not from all\nrefs.\n\n-- \nYann Dirson - Bertin Technologies\n"},{"id":"155575","messageId":"23523534-F7A7-4D61-A899-8B3B28566EA7@sb.org","threadId":"25685","inReplyTo":"20101110083209.6a1252ef@chalon.bertin.fr","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-11-10T07:46:59Z","receivedAt":"2010-11-10T07:46:59Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Nov 9, 2010, at 11:32 PM, Yann Dirson wrote:\n\n>> Another thing to consider - the current :/foo syntax searches for the\n>> newest commit reachable from any ref. Using the ^{} syntax will\n>> require specifying a ref first. I'm not sure this is a problem\n>> though, as I'm not really sure why :/foo searches from all refs to\n>> begin with.\n> \n> The syntax could be extended so that ^{whatever} starts looking at\n> current commit (ie. HEAD), somewhat like @{whatever} looks at reflog for\n> current branch.\n\n:/foo doesn't start from the current commit - it searches all refs. However,\nmaking ^{} search all refs if not given one doesn't make sense for any\noperator except :/foo, so I don't think it's worth doing\n\n-Kevin Ballard\n"},{"id":"155593","messageId":"m3eiatfbg2.fsf@localhost.localdomain","threadId":"25685","inReplyTo":"20101110084609.78f532a5@chalon.bertin.fr","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-11-10T15:26:20Z","receivedAt":"2010-11-10T15:26:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Yann Dirson writes:\n> On Tue, 09 Nov 2010 23:46:59 -0800\n> Kevin Ballard wrote:\n>> On Nov 9, 2010, at 11:32 PM, Yann Dirson wrote:\n>> \n>>>> Another thing to consider - the current :/foo syntax searches for\n>>>> the newest commit reachable from any ref. Using the ^{} syntax will\n>>>> require specifying a ref first. I'm not sure this is a problem\n>>>> though, as I'm not really sure why :/foo searches from all refs to\n>>>> begin with.\n>>> \n>>> The syntax could be extended so that ^{whatever} starts looking at\n>>> current commit (ie. HEAD), somewhat like @{whatever} looks at\n>>> reflog for current branch.\n\nThe @ is about reflogs: @{}, @{},\n@{-}, @{upstream} / @{u}. Because HEAD has separate\nreflog, then @{} is about current branch reflog (@{-} uses\nHEAD reflog, though). must be something that has reflog.\n\nThe ^ is about dereferencing: ^{} and ^{},\nwhich includes following parents ^ and ^. Then\nthere are odd ^! (returning range) and ^@\n(all parents) but which nevertheless follow this rule.\n\nThe : is (with single exception of ':/') about\nselecting subitem (path): :, [:]:\n\n>> \n>> :/foo doesn't start from the current commit - it searches all refs.\n>> However, making ^{} search all refs if not given one doesn't make\n>> sense for any operator except :/foo, so I don't think it's worth doing\n> \n> Yes, that's why I suggested to make it search from HEAD, not from all\n> refs.\n\nPerhaps '--all^{/foo}'? Just kidding... I think ;-)\n\n\nAbout n-th match: I think that ^{/foo} or ^{:/foo}... or\n^{:nth()/foo} as generic form of e.g. ^{3rd/foo} a la Perl 6 :-)\nOr perhaps even full form ^{m:nth()/foo}... well, perhaps not.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"155598","messageId":"1289407021-30287-1-git-send-email-pclouds@gmail.com","threadId":"25685","inReplyTo":"m3eiatfbg2.fsf@localhost.localdomain","subject":"[PATCH] get_sha1: support relative path \":\" syntax","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-10T16:37:01Z","receivedAt":"2010-11-10T16:37:01Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Currently :path and ref:path can be used to refer to a specific object\nin index or ref respectively. \"path\" component is absolute path. This\npatch allows \"path\" to be written as \"./path\" or \"../path\", which is\nrelative to user's original cwd.\n\nThis does not work in commands that startup_info is NULL\n(i.e. non-builtin ones).\n---\n On Wed, Nov 10, 2010 at 07:26:20AM -0800, Jakub Narebski wrote:\n > The : is (with single exception of ':/') about\n > selecting subitem (path): :, [:]:\n\n I feel the urge of keeping ':./path' and ':../path' out of this\n competition.\n\n The idea is old although I don't remember if anybody has made any\n attempt to realize it: use './' and '../' to specify the given path\n is relative, not absolute.\n\n I don't remember either if the idea was rejected or nobody bothered\n to implement it. Anyway, here it is (for demostration only because it\n needs two minor patches to work). Comments?\n --\n Duy\n\n sha1_name.c | 30 +++++++++++++++++++++++++++---\n 1 files changed, 27 insertions(+), 3 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 484081d..791608d 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -1060,25 +1060,35 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,\n \tif (!ret)\n \t\treturn ret;\n \t/* sha1:path --> object name of path in ent sha1\n-\t * :path -> object name of path in index\n+\t * :path -> object name of absolute path in index\n+\t * :./path -> object name of path relative to cwd in index\n \t * :[0-3]:path -> object name of path in index at stage\n \t * :/foo -> recent commit matching foo\n \t */\n \tif (name[0] == ':') {\n \t\tint stage = 0;\n \t\tstruct cache_entry *ce;\n+\t\tchar *new_path = NULL;\n \t\tint pos;\n \t\tif (namelen > 2 && name[1] == '/')\n \t\t\treturn get_sha1_oneline(name + 2, sha1);\n \t\tif (namelen < 3 ||\n \t\t name[2] != ':' ||\n-\t\t name[1] < '0' || '3' < name[1])\n+\t\t name[1] < '0' || '3' < name[1]) {\n \t\t\tcp = name + 1;\n+\t\t\tif (startup_info && cp[0] == '.' &&\n+\t\t\t (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) {\n+\t\t\t\tnew_path = prefix_path(startup_info->prefix,\n+\t\t\t\t\t\t strlen(startup_info->prefix),\n+\t\t\t\t\t\t cp);\n+\t\t\t\tcp = new_path;\n+\t\t\t}\n+\t\t}\n \t\telse {\n \t\t\tstage = name[1] - '0';\n \t\t\tcp = name + 3;\n \t\t}\n-\t\tnamelen = namelen - (cp - name);\n+\t\tnamelen = strlen(cp);\n \n \t\tstrncpy(oc->path, cp,\n \t\t\tsizeof(oc->path));\n@@ -1096,12 +1106,14 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,\n \t\t\t\tbreak;\n \t\t\tif (ce_stage(ce) == stage) {\n \t\t\t\thashcpy(sha1, ce->sha1);\n+\t\t\t\tfree(new_path);\n \t\t\t\treturn 0;\n \t\t\t}\n \t\t\tpos++;\n \t\t}\n \t\tif (!gently)\n \t\t\tdiagnose_invalid_index_path(stage, prefix, cp);\n+\t\tfree(new_path);\n \t\treturn -1;\n \t}\n \tfor (cp = name, bracket_depth = 0; *cp; cp++) {\n@@ -1122,6 +1134,17 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,\n \t\t}\n \t\tif (!get_sha1_1(name, cp-name, tree_sha1)) {\n \t\t\tconst char *filename = cp+1;\n+\t\t\tchar *new_filename = NULL;\n+\n+\t\t\tif (startup_info &&\n+\t\t\t filename[0] == '.' &&\n+\t\t\t (filename[1] == '/' ||\n+\t\t\t (filename[1] == '.' && filename[2] == '/'))) {\n+\t\t\t\tnew_filename = prefix_path(startup_info->prefix,\n+\t\t\t\t\t\t\t strlen(startup_info->prefix),\n+\t\t\t\t\t\t\t filename);\n+\t\t\t\tfilename = new_filename;\n+\t\t\t}\n \t\t\tret = get_tree_entry(tree_sha1, filename, sha1, &oc->mode);\n \t\t\tif (!gently) {\n \t\t\t\tdiagnose_invalid_sha1_path(prefix, filename,\n@@ -1133,6 +1156,7 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,\n \t\t\t\tsizeof(oc->path));\n \t\t\toc->path[sizeof(oc->path)-1] = '\\0';\n \n+\t\t\tfree(new_filename);\n \t\t\treturn ret;\n \t\t} else {\n \t\t\tif (!gently)\n-- \n1.7.3.2.210.g045198\n"},{"id":"155603","messageId":"vpq39r9m729.fsf@bauges.imag.fr","threadId":"25685","inReplyTo":"1289407021-30287-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] get_sha1: support relative path \":\" syntax","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-11-10T17:17:50Z","receivedAt":"2010-11-10T17:17:50Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Currently :path and ref:path can be used to refer to a specific object\n> in index or ref respectively. \"path\" component is absolute path. This\n> patch allows \"path\" to be written as \"./path\" or \"../path\", which is\n> relative to user's original cwd.\n>\n> This does not work in commands that startup_info is NULL\n\nGrammar: shouldn't it be \"commands for which startup_info is NULL\"?\n\n> (i.e. non-builtin ones).\n\nDoes that include \"git show\"? That's probably the most common use-case\nfor the : syntax, perhaps worth mentionning here.\n\nAlso, what happens when it doesn't work? I guess it falls back to the\nprevious behavior, which tries to do a detailed diagnosis and provides\na general error message. But probably the error messages should be\nreworded to include \"syntax not supported by this command\" or so,\n'cause it's really weird for a user to be able to say HEAD:./foo in\nsome places and not in others.\n\n> The idea is old although I don't remember if anybody has made any\n> attempt to realize it: use './' and '../' to specify the given path\n> is relative, not absolute.\n\nI gave it a try, but I was not aware of the startup_info thing, and\ntried passing more arguments to get_sha1*, and you can guess I quickly\ngave up ;-).\n\n> +\t\t\tif (startup_info && cp[0] == '.' &&\n> +\t\t\t (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) {\n\nNothing performance-critical here, so I'd rather have something more\nreadable, like\n\nstartup_info && (!prefixcmp(cp, \"./\") || !prefixcmp(cp, \"../\"))\n\n\n> +\t\t\t\tnew_path = prefix_path(startup_info->prefix,\n> +\t\t\t\t\t\t strlen(startup_info->prefix),\n> +\t\t\t\t\t\t cp);\n\nfree(cp); here?\n\n> +\t\t\t\tcp = new_path;\n> +\t\t\t}\n> +\t\t}\n\n> @@ -1122,6 +1134,17 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,\n> \t\t}\n> \t\tif (!get_sha1_1(name, cp-name, tree_sha1)) {\n> \t\t\tconst char *filename = cp+1;\n> +\t\t\tchar *new_filename = NULL;\n> +\n> +\t\t\tif (startup_info &&\n> +\t\t\t filename[0] == '.' &&\n> +\t\t\t (filename[1] == '/' ||\n> +\t\t\t (filename[1] == '.' && filename[2] == '/'))) {\n> +\t\t\t\tnew_filename = prefix_path(startup_info->prefix,\n> +\t\t\t\t\t\t\t strlen(startup_info->prefix),\n> +\t\t\t\t\t\t\t filename);\n\nSame 2 questions as above.\n\nAlso, that would be nice is this came with a testcase :-)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"155600","messageId":"7vsjz9hz2p.fsf@alter.siamese.dyndns.org","threadId":"25685","inReplyTo":"m3eiatfbg2.fsf@localhost.localdomain","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-10T17:23:58Z","receivedAt":"2010-11-10T17:23:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> The @ is about reflogs\n\nWrong. \"@\" in the olden days were limited about reflogs but not these\ndays. @ is about refs; ^ is about\nobjects (most often commits).\n"},{"id":"155606","messageId":"20101110174736.GD11513@burratino","threadId":"25685","inReplyTo":"1289407021-30287-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] get_sha1: support relative path \":\" syntax","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-10T17:47:36Z","receivedAt":"2010-11-10T17:47:36Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyễn Thái Ngọc Duy wrote:\n\n> This does not work in commands that startup_info is NULL\n> (i.e. non-builtin ones).\n\nThat is easily fixable, no?\n\nThe non-builtins are:\n\n\tfast-import\n\timap-send\n\tshell\n\tdaemon\n\tshow-index\n\tupload-pack\n\thttp-backend\n\thttp-fetch\n\thttp-push\n\nOf those, only fast-import might have a possible reason need to know\nabout this new syntax.\n\nSigned-off-by: Jonathan Nieder \n---\n Assuming your patch builds on acf4823a (setup: save prefix (original\n cwd relative to toplevel) in startup_info, 2010-10-24).\n\n Untested.\n\ndiff --git a/fast-import.c b/fast-import.c\nindex 77549eb..3b597e8 100644\n--- a/fast-import.c\n+++ b/fast-import.c\n@@ -2923,8 +2923,11 @@ static void parse_argv(void)\n \n int main(int argc, const char **argv)\n {\n+\tstatic struct startup_info git_startup_info;\n \tunsigned int i;\n \n+\tstartup_info = &git_startup_info;\n+\n \tgit_extract_argv0_path(argv[0]);\n \n \tif (argc == 2 && !strcmp(argv[1], \"-h\"))\n"},{"id":"155607","messageId":"201011101919.32848.jnareb@gmail.com","threadId":"25685","inReplyTo":"7vsjz9hz2p.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-11-10T18:19:31Z","receivedAt":"2010-11-10T18:19:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 10 Nov 2010, Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n> > The @ is about reflogs\n> \n> Wrong. \"@\" in the olden days were limited about reflogs but not these\n> days. @ is about refs; ^ is about\n> objects (most often commits).\n\nFact. I even provided example, and didn't notice it: []@{upstream}\ndoes not use reflogs, but config.\n-- \nJakub Narebski\nPoland\n"},{"id":"155613","messageId":"7veiatht1b.fsf@alter.siamese.dyndns.org","threadId":"25685","inReplyTo":"1289407021-30287-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] get_sha1: support relative path \":\" syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-10T19:34:24Z","receivedAt":"2010-11-10T19:34:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> \t\tif (namelen < 3 ||\n> \t\t name[2] != ':' ||\n> -\t\t name[1] < '0' || '3' < name[1])\n> +\t\t name[1] < '0' || '3' < name[1]) {\n> \t\t\tcp = name + 1;\n> +\t\t\tif (startup_info && cp[0] == '.' &&\n> +\t\t\t (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) {\n> +\t\t\t\tnew_path = prefix_path(startup_info->prefix,\n> +\t\t\t\t\t\t strlen(startup_info->prefix),\n> +\t\t\t\t\t\t cp);\n> +\t\t\t\tcp = new_path;\n> +\t\t\t}\n> +\t\t}\n\nWhat does this new codepath do when we know where the working tree is and\nwe are outside of the working tree (e.g. we are looking at the index or a\ncommit in a submodule from above the superproject)?\n\nWhat should it do?\n"},{"id":"155640","messageId":"AANLkTimxR1YV+D2HBHUr8bCbrT7XyHfKoMN71raUZ3Jx@mail.gmail.com","threadId":"25685","inReplyTo":"7veiatht1b.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] get_sha1: support relative path \":\" syntax","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-11T01:30:42Z","receivedAt":"2010-11-11T01:30:42Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2010/11/11 Junio C Hamano :\n> Nguyễn Thái Ngọc Duy   writes:\n>\n>>               if (namelen < 3 ||\n>>                   name[2] != ':' ||\n>> -                 name[1] < '0' || '3' < name[1])\n>> +                 name[1] < '0' || '3' < name[1]) {\n>>                       cp = name + 1;\n>> +                     if (startup_info && cp[0] == '.' &&\n>> +                         (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) {\n>> +                             new_path = prefix_path(startup_info->prefix,\n>> +                                                    strlen(startup_info->prefix),\n>> +                                                    cp);\n>> +                             cp = new_path;\n>> +                     }\n>> +             }\n>\n> What does this new codepath do when we know where the working tree is and\n> we are outside of the working tree (e.g. we are looking at the index or a\n> commit in a submodule from above the superproject)?\n>\n> What should it do?\n\nPrefix is NULL in that case. So no prefixing, git will complain the\ngiven path does not exist (although it should say \"./\" syntax is not\nusable without a worktree).\n\nprefix_path() dies if the resolved path is outside repo. So no, users\ncan't look up files in superproject from a subproject. I think we need\nto define the superproject/subproject relation first. I have\n$HOME/.git, but I don't think it's a superproject to any repos inside\nmy $HOME.\n-- \nDuy\n"},{"id":"155684","messageId":"AANLkTimuN2Ese-Am+Ydr6n1A9YGhFauUit_da0ici5bL@mail.gmail.com","threadId":"25685","inReplyTo":"20101110174736.GD11513@burratino","subject":"Re: [PATCH] get_sha1: support relative path \":\" syntax","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-11T13:18:52Z","receivedAt":"2010-11-11T13:18:52Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2010/11/11 Jonathan Nieder :\n> Nguyễn Thái Ngọc Duy wrote:\n>\n>> This does not work in commands that startup_info is NULL\n>> (i.e. non-builtin ones).\n>\n> That is easily fixable, no?\n\nLaziness is a big factor to me (or maybe I'm just tired after work).\nIn the meantime I'll take your analysis and fix fast-import. Thanks.\n-- \nDuy\n"},{"id":"157727","messageId":"7vipz2fy98.fsf@alter.siamese.dyndns.org","threadId":"25685","inReplyTo":"1289407021-30287-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] get_sha1: support relative path \":\" syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-09T21:10:43Z","receivedAt":"2010-12-09T21:10:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Currently :path and ref:path can be used to refer to a specific object\n> in index or ref respectively. \"path\" component is absolute path. This\n> patch allows \"path\" to be written as \"./path\" or \"../path\", which is\n> relative to user's original cwd.\n>\n> This does not work in commands that startup_info is NULL\n> (i.e. non-builtin ones).\n> ---\n> On Wed, Nov 10, 2010 at 07:26:20AM -0800, Jakub Narebski wrote:\n> > The : is (with single exception of ':/') about\n> > selecting subitem (path): :, [:]:\n>\n> I feel the urge of keeping ':./path' and ':../path' out of this\n> competition.\n>\n> The idea is old although I don't remember if anybody has made any\n> attempt to realize it: use './' and '../' to specify the given path\n> is relative, not absolute.\n\nI've had this queued for some time, with help from Jonathan, and am happy\nabout it in general, but after taking another look at it, noticed one\nminor thing.\n\n> diff --git a/sha1_name.c b/sha1_name.c\n> index 484081d..791608d 100644\n> --- a/sha1_name.c\n> +++ b/sha1_name.c\n> @@ -1060,25 +1060,35 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,\n> \tif (!ret)\n> \t\treturn ret;\n> \t/* sha1:path --> object name of path in ent sha1\n> -\t * :path -> object name of path in index\n> +\t * :path -> object name of absolute path in index\n> +\t * :./path -> object name of path relative to cwd in index\n> \t * :[0-3]:path -> object name of path in index at stage\n> \t * :/foo -> recent commit matching foo\n> \t */\n> \tif (name[0] == ':') {\n> \t\tint stage = 0;\n> \t\tstruct cache_entry *ce;\n> +\t\tchar *new_path = NULL;\n> \t\tint pos;\n> \t\tif (namelen > 2 && name[1] == '/')\n> \t\t\treturn get_sha1_oneline(name + 2, sha1);\n> \t\tif (namelen < 3 ||\n> \t\t name[2] != ':' ||\n> -\t\t name[1] < '0' || '3' < name[1])\n> +\t\t name[1] < '0' || '3' < name[1]) {\n> \t\t\tcp = name + 1;\n> +\t\t\tif (startup_info && cp[0] == '.' &&\n> +\t\t\t (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) {\n> +\t\t\t\tnew_path = prefix_path(startup_info->prefix,\n> +\t\t\t\t\t\t strlen(startup_info->prefix),\n> +\t\t\t\t\t\t cp);\n> +\t\t\t\tcp = new_path;\n> +\t\t\t}\n> +\t\t}\n\nThis deals with \":$foo\" (path $foo in the index), which is a shorthand for\n\":0:$foo\" (the path $foo at stage #0 in the index). However...\n\n> \t\telse {\n> \t\t\tstage = name[1] - '0';\n> \t\t\tcp = name + 3;\n\n... this side does not do anything about it, so:\n\n\t$ cd Documentation\n ... working for a while ...\n $ git merge another_branch\n ... oops, got conflicts at ../Makefile\n\t$ git show :2:../Makefile\n\nwon't work.\n\nBesides, it is a bad idea to make \":../Makefile\" work while leaving\nits longhand \":0:../Makefile\" not.\n\nI think it is just the matter of moving \"if (startup-info)...\" logic\noutside the \"is the :$path lacking an explicit stage number\" block and\nhaving it after that if/else, no?\n"},{"id":"157731","messageId":"7v7hfifx00.fsf@alter.siamese.dyndns.org","threadId":"25685","inReplyTo":"7vipz2fy98.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] get_sha1: support relative path \":\" syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-09T21:37:51Z","receivedAt":"2010-12-09T21:37:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I think it is just the matter of moving \"if (startup-info)...\" logic\n> outside the \"is the :$path lacking an explicit stage number\" block and\n> having it after that if/else, no?\n\nLike this, perhaps?\n\n-- >8 --\nSubject: get_sha1: teach \":$n:\" the same relative path logic\n\nEarlier we taught the object name parser \":\" syntax that uses a path\nrelative to the current working directory. Given that \":\" is just a\nshort-hand for \":0:\" (i.e. \"take stage #0 of that path\"), we should\nallow \":$n:\" to use relative path the same way.\n\nSigned-off-by: Junio C Hamano \n---\n sha1_name.c | 14 ++++++++------\n t/t1506-rev-parse-diagnosis.sh | 24 ++++++++++++++++++++++++\n 2 files changed, 32 insertions(+), 6 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex f918faf..2074056 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -1091,17 +1091,19 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,\n \t\t\treturn get_sha1_oneline(name + 2, sha1);\n \t\tif (namelen < 3 ||\n \t\t name[2] != ':' ||\n-\t\t name[1] < '0' || '3' < name[1]) {\n+\t\t name[1] < '0' || '3' < name[1])\n \t\t\tcp = name + 1;\n-\t\t\tnew_path = resolve_relative_path(cp);\n-\t\t\tif (new_path)\n-\t\t\t\tcp = new_path;\n-\t\t}\n \t\telse {\n \t\t\tstage = name[1] - '0';\n \t\t\tcp = name + 3;\n \t\t}\n-\t\tnamelen = strlen(cp);\n+\t\tnew_path = resolve_relative_path(cp);\n+\t\tif (!new_path) {\n+\t\t\tnamelen = namelen - (cp - name);\n+\t\t} else {\n+\t\t\tcp = new_path;\n+\t\t\tnamelen = strlen(cp);\n+\t\t}\n \n \t\tstrncpy(oc->path, cp,\n \t\t\tsizeof(oc->path));\ndiff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh\nindex 1866470..9f8adb1 100755\n--- a/t/t1506-rev-parse-diagnosis.sh\n+++ b/t/t1506-rev-parse-diagnosis.sh\n@@ -34,6 +34,8 @@ test_expect_success 'correct file objects' '\n test_expect_success 'correct relative file objects (0)' '\n \tgit rev-parse :file.txt >expected &&\n \tgit rev-parse :./file.txt >result &&\n+\ttest_cmp expected result &&\n+\tgit rev-parse :0:./file.txt >result &&\n \ttest_cmp expected result\n '\n \n@@ -68,6 +70,28 @@ test_expect_success 'correct relative file objects (4)' '\n \t)\n '\n \n+test_expect_success 'correct relative file objects (5)' '\n+\tgit rev-parse :subdir/file.txt >expected &&\n+\t(\n+\t\tcd subdir &&\n+\t\tgit rev-parse :./file.txt >result &&\n+\t\ttest_cmp ../expected result &&\n+\t\tgit rev-parse :0:./file.txt >result &&\n+\t\ttest_cmp ../expected result\n+\t)\n+'\n+\n+test_expect_success 'correct relative file objects (6)' '\n+\tgit rev-parse :file.txt >expected &&\n+\t(\n+\t\tcd subdir &&\n+\t\tgit rev-parse :../file.txt >result &&\n+\t\ttest_cmp ../expected result &&\n+\t\tgit rev-parse :0:../file.txt >result &&\n+\t\ttest_cmp ../expected result\n+\t)\n+'\n+\n test_expect_success 'incorrect revision id' '\n \ttest_must_fail git rev-parse foobar:file.txt 2>error &&\n \tgrep \"Invalid object name '\"'\"'foobar'\"'\"'.\" error &&\n"},{"id":"157782","messageId":"AANLkTimYcdLmqj=db45nzsDShsAMTnsRJHhLJwtxDDai@mail.gmail.com","threadId":"25685","inReplyTo":"7v7hfifx00.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] get_sha1: support relative path \":\" syntax","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-10T01:35:20Z","receivedAt":"2010-12-10T01:35:20Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2010/12/10 Junio C Hamano :\n> Junio C Hamano writes:\n>\n>> I think it is just the matter of moving \"if (startup-info)...\" logic\n>> outside the \"is the :$path lacking an explicit stage number\" block and\n>> having it after that if/else, no?\n>\n> Like this, perhaps?\n\nYeah, looks good. Sorry I missed that else block.\n-- \nDuy\n"}]}