{"thread":{"id":"14270","subject":"':/' notation doesn't support full file syntax","startedAt":"2008-07-03T05:42:52Z","lastAt":"2008-07-04T00:33:51Z","messageCount":9,"participants":["Eric Raible","Junio C Hamano","Jeff King","Johannes Schindelin","Dana How"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"82090","messageId":"279b37b20807022242q69ad2fcbwb8c11a9d6165272d@mail.gmail.com","threadId":"14270","inReplyTo":null,"subject":"':/' notation doesn't support full file syntax","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-07-03T05:42:52Z","receivedAt":"2008-07-03T05:42:52Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Although the rev-parse documentation claims that the\ntree-ish:path/to/file syntax works is applicable, this is\nnot so when using the :/ \"oneline prefix\" syntax:\n\n% git rev-parse v1.5.0.1-227-g28a4d94\n28a4d940443806412effa246ecc7768a21553ec7\n% git rev-parse \":/object name\"\n28a4d940443806412effa246ecc7768a21553ec7\n\n% git rev-parse v1.5.0.1-227-g28a4d94:sha1_name.c\n0781477a71ac4d76a1b8783868d6649cae7f8507\n% git rev-parse \":/object name\":sha1_name.c\n:/object name:sha1_name.c\nfatal: ambiguous argument ':/object name:sha1_name.c': unknown\nrevision or path not in the working tree.\nUse '--' to separate paths from revisions\n\nA quick look at int sha1_name.c:get_sha1() shows that it doesn't\neven try to make this work. Is this worth fixing?\nOr at least documenting?\n\n- Eric\n"},{"id":"82109","messageId":"7vfxqr2won.fsf@gitster.siamese.dyndns.org","threadId":"14270","inReplyTo":"279b37b20807022242q69ad2fcbwb8c11a9d6165272d@mail.gmail.com","subject":"Re: ':/' notation doesn't support full file syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-03T08:34:16Z","receivedAt":"2008-07-03T08:34:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric Raible\" writes:\n\n> % git rev-parse \":/object name\":sha1_name.c\n> :/object name:sha1_name.c\n> fatal: ambiguous argument ':/object name:sha1_name.c': unknown\n> revision or path not in the working tree.\n> Use '--' to separate paths from revisions\n>\n> A quick look at int sha1_name.c:get_sha1() shows that it doesn't\n> even try to make this work. Is this worth fixing?\n\nIs there anything to fix? In that example, you are looking for a commit\nthat talks about \"object name:sha1_name.c\" in the comment.\n"},{"id":"82127","messageId":"279b37b20807030150t2e9cbcc8wf099a5872568af8@mail.gmail.com","threadId":"14270","inReplyTo":"7vfxqr2won.fsf@gitster.siamese.dyndns.org","subject":"Re: ':/' notation doesn't support full file syntax","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-07-03T08:50:18Z","receivedAt":"2008-07-03T08:50:18Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Thu, Jul 3, 2008 at 1:34 AM, Junio C Hamano wrote:\n> \"Eric Raible\" writes:\n>\n> Is there anything to fix? In that example, you are looking for a commit\n> that talks about \"object name:sha1_name.c\" in the comment.\n\nYes. What if I'm looking for specific file (i.e. sha1_name.c) in the commit\ndescribed by \":/object name:\", just like I can do with 28a4d9404:sha1_name.c?\n\nThis is not ambiguous if we first consider the entire string as the prefix.\nIf that fails we look for a filename after the final ':'.\n\nI'll post a patch in a moment.\n\n- Eric\n"},{"id":"82115","messageId":"20080703104744.GB26162@sigill.intra.peff.net","threadId":"14270","inReplyTo":"279b37b20807022242q69ad2fcbwb8c11a9d6165272d@mail.gmail.com","subject":"Re: ':/' notation doesn't support full file syntax","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-03T10:47:45Z","receivedAt":"2008-07-03T10:47:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 02, 2008 at 10:42:52PM -0700, Eric Raible wrote:\n\n> Although the rev-parse documentation claims that the\n> tree-ish:path/to/file syntax works is applicable, this is\n> not so when using the :/ \"oneline prefix\" syntax:\n> \n> % git rev-parse v1.5.0.1-227-g28a4d94\n> 28a4d940443806412effa246ecc7768a21553ec7\n> % git rev-parse \":/object name\"\n> 28a4d940443806412effa246ecc7768a21553ec7\n> \n> % git rev-parse v1.5.0.1-227-g28a4d94:sha1_name.c\n> 0781477a71ac4d76a1b8783868d6649cae7f8507\n> % git rev-parse \":/object name\":sha1_name.c\n> :/object name:sha1_name.c\n> fatal: ambiguous argument ':/object name:sha1_name.c': unknown\n> revision or path not in the working tree.\n> Use '--' to separate paths from revisions\n> \n> A quick look at int sha1_name.c:get_sha1() shows that it doesn't\n> even try to make this work. Is this worth fixing?\n> Or at least documenting?\n\nIMHO, :/ should stop eating text at the first ':', and allow '\\:' for\na literal colon and '\\\\' for a literal backslash.\n\nI think nobody has really cared up to this point (and I can't say that I\ncare that much now, but I wouldn't object to such a patch).\n\n-Peff\n"},{"id":"82118","messageId":"alpine.DEB.1.00.0807031333150.9925@racer","threadId":"14270","inReplyTo":"279b37b20807030150t2e9cbcc8wf099a5872568af8@mail.gmail.com","subject":"Re: ':/' notation doesn't support full file syntax","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-03T12:38:57Z","receivedAt":"2008-07-03T12:38:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 3 Jul 2008, Eric Raible wrote:\n\n> On Thu, Jul 3, 2008 at 1:34 AM, Junio C Hamano wrote:\n> > \"Eric Raible\" writes:\n> >\n> > Is there anything to fix? In that example, you are looking for a \n> > commit that talks about \"object name:sha1_name.c\" in the comment.\n> \n> Yes. What if I'm looking for specific file (i.e. sha1_name.c) in the \n> commit described by \":/object name:\", just like I can do with \n> 28a4d9404:sha1_name.c?\n> \n> This is not ambiguous if we first consider the entire string as the \n> prefix. If that fails we look for a filename after the final ':'.\n\nIt is super-expensive, as you have to look through the whole history just \nto find that you do not find anything.\n\nAnd then, it could be that you do find a commit that starts with that \nstring, but what you really wanted it a file, not a commit.\n\nAnd then, a file name can contain colons. What to do in that case?\n\nI think your \"fix\" is not worth it. \":/\" is to help you find a \ncommit, and it will only ever find the first commit anyway, so you are \nprobably better off using\n\n\t$ git show $(git log --pretty=format:%H:path/to/file.c \\\n\t\t--grep=^)\n\nto begin with.\n\nReally, the only reason I ever wrote support for \":/blah\" is when someone \nless-than-helpful says \"In commit 'Bla bla bla' you broke XYZ\" and I want \nto\n\t$ git show :/Bla\n\nNowadays, however, I would\n\n\t$ git log -p --grep=^Bla\n\nso I'd vote to remove the \":/\" syntax altogether. We need not even \nconcern ourselves with scripts using that syntax, since the semantics are \nso limited that nobody should use it in scripts anyway.\n\nCiao,\nDscho\n"},{"id":"82140","messageId":"56b7f5510807031127j10e33f3bl516180f7a9b5b5db@mail.gmail.com","threadId":"14270","inReplyTo":"279b37b20807030150t2e9cbcc8wf099a5872568af8@mail.gmail.com","subject":"Re: ':/' notation doesn't support full file syntax","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2008-07-03T18:27:01Z","receivedAt":"2008-07-03T18:27:01Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Thu, Jul 3, 2008 at 1:50 AM, Eric Raible wrote:\n> On Thu, Jul 3, 2008 at 1:34 AM, Junio C Hamano wrote:\n>> \"Eric Raible\" writes:\n>>\n>> Is there anything to fix? In that example, you are looking for a commit\n>> that talks about \"object name:sha1_name.c\" in the comment.\n>\n> Yes. What if I'm looking for specific file (i.e. sha1_name.c) in the commit\n> described by \":/object name:\", just like I can do with 28a4d9404:sha1_name.c?\n>\n> This is not ambiguous if we first consider the entire string as the prefix.\n> If that fails we look for a filename after the final ':'.\n\nIn part you are proposing this because it is a consistent extension.\nBut a problem with the current :/string is that it adds 2nd meanings\nto both : and / ,\nwhich is not all that consistent to start with.\n\nLast year Junio proposed that :/ be changed to ?\nto eliminate the overloading; thus your proposal becomes:\n ?string:filename\nHe chose ? because it results in a search backwards through commits.\n(You could make that ?string?:filename if you prefer, where the 2nd ?\n is only needed if you include a filename.)\n\nI was surprised to see Dscho advocating removing this feature altogether.\nOthers proposed other command sequences which avoided :/ .\nIf :/ is now going to be extended and thus perhaps more likely to\nappear in scripts,\nis now the time to change it to ? which has no other special meaning to git?\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"82160","messageId":"7v7ic2zmjp.fsf@gitster.siamese.dyndns.org","threadId":"14270","inReplyTo":"56b7f5510807031127j10e33f3bl516180f7a9b5b5db@mail.gmail.com","subject":"Re: ':/' notation doesn't support full file syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-03T21:26:50Z","receivedAt":"2008-07-03T21:26:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Dana How\" writes:\n\n> I was surprised to see Dscho advocating removing this feature altogether.\n> Others proposed other command sequences which avoided :/ .\n> If :/ is now going to be extended and thus perhaps more likely to\n> appear in scripts,\n> is now the time to change it to ? which has no other special meaning to git?\n\nThere are number of problems with \":/\" notation, but my biggest gripe is\nthat it is only slightly better than \"give back a random commit\". You\ncannot even tell it to \"dig from these branch tips, look for the first one\nthat talks about this text\".\n\nAs Dscho mentioned, --grep works much better and instead of saying:\n\n $ git diff ':/send-email' HEAD\n\nwe can say:\n\n $ git diff \\\n $(git log --pretty=format:%H -1 --grep=send-email master next) HEAD\n\nThe error behaviour is somewhat different between the two, though. When\nyou misspell what to grep, the command substitution will give empty and\nyou would get an unexpected result. Being built-in, ':/' syntax can say\n\"I do not find anything that match\" fairly easily, and the command\nsubstitution version has to say something ugly like:\n\n $ git diff \\\n $(\n x=$(git log --pretty=format:%H -1 --grep=send-email master next)\n case \"$x\" in\n ('') echo 0000000000000000000000000000000000000000 ;;\n (?) echo $x ;; esac\n ) HEAD\n\nto get a similar effect.\n\nBut the point is that you can extend it easily with the :path suffix if\nyou wanted to:\n\n $ git show \\\n $(git log --pretty=format:%H -1 --grep=send-email):git-send-email.perl\n\nYou can even alias \"log --pretty=format:%H -1\" if you wanted to, and use\nrevision limiter other than --grep, like this:\n\n (in .git/config)\n\n\t[alias]\n \tpick = log --pretty=format:%H -1\n\n $ git diff --stat $(git pick -- Documentation)^\n $ git blame $(git pick pu -- remote.c) remote.c\n\nSo in short, ':/' is limited (cannot be suffixed with :path, cannot be\ntold to dig down from named revs, etc.) but you can do what ':/' cannot do\nfairly easily with command substitution.\n\nHowever, $(git pick --all --grep=something), without suffixed modifiers\nsuch as ~$N and :$path, may still be common enough that it might deserve a\nshort-hand ':/' (and that is why we have it).\n\nIf people do not find that short-hand useful, I am not strongly opposed to\nthe idea of dropping it. I personally find the notation not very useful\ncute hack anyway ;-).\n"},{"id":"82182","messageId":"alpine.DEB.1.00.0807040206360.2849@eeepc-johanness","threadId":"14270","inReplyTo":"7v7ic2zmjp.fsf@gitster.siamese.dyndns.org","subject":"Re: ':/' notation doesn't support full file syntax","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-04T00:14:34Z","receivedAt":"2008-07-04T00:14:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 3 Jul 2008, Junio C Hamano wrote:\n\n> \"Dana How\" writes:\n> \n> > I was surprised to see Dscho advocating removing this feature \n> > altogether. Others proposed other command sequences which avoided :/ . \n> > If :/ is now going to be extended and thus perhaps more likely to \n> > appear in scripts, is now the time to change it to ? which has no \n> > other special meaning to git?\n> \n> There are number of problems with \":/\" notation, but my biggest gripe is \n> that it is only slightly better than \"give back a random commit\".\n\nWell, it _is_ better than that: it gives you the _newest_ matching commit, \nprovided that the people involved in those commits maintained their NTP \nsettings correctly.\n\nThe _real_ gripe you should have with the notation is what I pointed out \nalready: it is _ill_-defined. It _could_ match more than one commit, but \nmatches only _one_.\n\n> As Dscho mentioned, --grep works much better and instead of saying:\n> \n> $ git diff ':/send-email' HEAD\n> \n> we can say:\n> \n> $ git diff \\\n> $(git log --pretty=format:%H -1 --grep=send-email master next) HEAD\n> \n> The error behaviour is somewhat different between the two, though. \n> When you misspell what to grep, the command substitution will give empty \n> and you would get an unexpected result. Being built-in, ':/' syntax can \n> say \"I do not find anything that match\" fairly easily, and the command \n> substitution version has to say something ugly like:\n> \n> $ git diff \\\n> $(\n> x=$(git log --pretty=format:%H -1 --grep=send-email master next)\n> case \"$x\" in\n> ('') echo 0000000000000000000000000000000000000000 ;;\n> (?) echo $x ;; esac\n> ) HEAD\n> \n> to get a similar effect.\n\nAgain, this is the wrong way to think about it. If you grep for things, \nyou can get 0..infty matches, not necessarily 1.\n\nTo assume that you get at least one match is already an error.\n\nLetting that funny \"case\" syntax slip by, I would suggest this command \nline instead:\n\n$ $(git log --pretty=format:'git diff %H..;' --grep=send-email \\\n\tmaster next)\n\n> But the point is that you can extend it easily with the :path suffix if \n> you wanted to:\n> \n> $ git show \\\n> $(git log --pretty=format:%H -1 \\\n> --grep=send-email):git-send-email.perl\n\nAgain, I would rather suggest pulling the \":\" into the format, as I \ndid _already_ in another mail, robustifying the whole command.\n\n> So in short, ':/' is limited (cannot be suffixed with :path, cannot be \n> told to dig down from named revs, etc.) but you can do what ':/' cannot \n> do fairly easily with command substitution.\n> \n> However, $(git pick --all --grep=something), without suffixed modifiers\n> such as ~$N and :$path, may still be common enough that it might deserve a\n> short-hand ':/' (and that is why we have it).\n> \n> If people do not find that short-hand useful, I am not strongly opposed to\n> the idea of dropping it. I personally find the notation not very useful\n> cute hack anyway ;-).\n\nIt was a cute hack, and before --grep it was actually useful.\n\nNow it is not any more,\nDscho\n"},{"id":"82183","messageId":"alpine.DEB.1.00.0807040232200.2849@eeepc-johanness","threadId":"14270","inReplyTo":"56b7f5510807031127j10e33f3bl516180f7a9b5b5db@mail.gmail.com","subject":"Re: ':/' notation doesn't support full file syntax","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-04T00:33:51Z","receivedAt":"2008-07-04T00:33:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 3 Jul 2008, Dana How wrote:\n\n> I was surprised to see Dscho advocating removing this feature \n> altogether.\n\nWhy is everybody surprised when I admit mistakes?\n\nGranted, --grep did not exist when I wrote :/ but now it does, and there \nis no good reason to keep an ill-defined construct in Git when we have \nsomething better.\n\nCiao,\nDscho\n"}]}