{"thread":{"id":"42052","subject":"[BUG] git rev-parse :/ \"regex\" syntax not really regex?","startedAt":"2016-04-17T13:37:41Z","lastAt":"2016-04-17T15:54:40Z","messageCount":3,"participants":["Andreas Mohr","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"283682","messageId":"20160417133741.GA28931@rhlx01.hs-esslingen.de","threadId":"42052","inReplyTo":null,"subject":"[BUG] git rev-parse :/ \"regex\" syntax not really regex?","fromName":"Andreas Mohr","fromEmail":"andi@lisas.de","sentAt":"2016-04-17T13:37:41Z","receivedAt":"2016-04-17T13:37:41Z","isPatch":false,"sender":{"key":"andi@lisas.de","avatar":null},"body":"Hello all,\n\nI just wanted to shortly mention that to me it seems\nthat while\ngit help rev-parse\nsays\n       :/<text>, e.g. :/fix nasty bug\n           A colon, followed by a slash, followed by a text, names a commit whose commit message matches the specified regular expression. This name returns the\n           youngest matching commit which is reachable from any ref. If the commit message starts with a !  you have to repeat that; the special sequence :/!, followed\n           by something else than !, is reserved for now. The regular expression can match any part of the commit message. To match messages starting with a string, one\n           can use e.g.  :/^foo.\n, the supported syntax seems to be decidedly not really regex,\nas opposed to\ngit log --grep\n\nCreating a minimal reproducing repo sample\nwith e.g. a dummy commit series of the following commit titles:\n\nMy commit last\nMy commit\nMy commit first\n\nand doing searches via\n  git rev-parse :/'^My commi\\w'\n  git rev-parse :/'^My commit$'\n  git rev-parse :/'^My commit'\n  git log --grep='^My commit$' --format=%H <---- that one seems to work fully reliably\n\nwill yield surprising results\n(returning most recent commit rather than commit title exact-match one),\nand no amount of fiddling with various regex flavour syntax deviations\nmanaged to fix it for me.\n\nUnless I happened to misunderstand git's regex flavour, or something else...\n(hmm, perhaps it's a try-match-single-line vs. multi-line content issue,\nwhich perhaps does not work by specifying the trailing $)\n\n\n$ git --version\ngit version 2.5.5\n\n(same irritating behaviour also encountered on some older version, perhaps 2.0/2.1 range)\n\n\nIf this bug is confirmed, then I could suggest two variants:\n- fix rev-parse's handling of :/ to actually do the correct thing, if easily possible\n- simply fix rev-parse's docs to correctly indicate\n  that unfortunately it is NOT fully regex capable,\n  and ensure also having added a reference to the (much?) more reliably working\n  git log --grep.\n\nIf this bug is not confirmed, then the question would be\nwhat kind of potential documentation / usability weaknesses\nsuccessfully managed to lead me astray\nand thus would need to be fixed.\n\nThanks,\n\nAndreas Mohr\n"},{"id":"283683","messageId":"87inzgtjfv.fsf@linux-m68k.org","threadId":"42052","inReplyTo":"20160417133741.GA28931@rhlx01.hs-esslingen.de","subject":"Re: [BUG] git rev-parse :/ \"regex\" syntax not really regex?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2016-04-17T14:10:28Z","receivedAt":"2016-04-17T14:10:28Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Andreas Mohr <andi@lisas.de> writes:\n\n> Unless I happened to misunderstand git's regex flavour, or something else...\n> (hmm, perhaps it's a try-match-single-line vs. multi-line content issue,\n> which perhaps does not work by specifying the trailing $)\n\nThis is exactly the difference.  git log --grep matches individual lines\n(like grep), whereas :/<regexp> matches against the whole commit message\nincluding embedded (and trailing) newlines, and $ doesn't match an\nembedded newline.  Thus to address the second commit in your example you\nhave to use $':/^My commit\\n' (using bash's ANSI-C quoting feature).\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"283686","messageId":"20160417155440.GA4817@rhlx01.hs-esslingen.de","threadId":"42052","inReplyTo":"87inzgtjfv.fsf@linux-m68k.org","subject":"Re: [BUG] git rev-parse :/ \"regex\" syntax not really regex?","fromName":"Andreas Mohr","fromEmail":"andi@lisas.de","sentAt":"2016-04-17T15:54:40Z","receivedAt":"2016-04-17T15:54:40Z","isPatch":false,"sender":{"key":"andi@lisas.de","avatar":null},"body":"On Sun, Apr 17, 2016 at 04:10:28PM +0200, Andreas Schwab wrote:\n> Andreas Mohr <andi@lisas.de> writes:\n> \n> > Unless I happened to misunderstand git's regex flavour, or something else...\n> > (hmm, perhaps it's a try-match-single-line vs. multi-line content issue,\n> > which perhaps does not work by specifying the trailing $)\n> \n> This is exactly the difference.  git log --grep matches individual lines\n> (like grep), whereas :/<regexp> matches against the whole commit message\n> including embedded (and trailing) newlines, and $ doesn't match an\n> embedded newline.  Thus to address the second commit in your example you\n> have to use $':/^My commit\\n' (using bash's ANSI-C quoting feature).\n\nAt first I thought \"no way, I already did try trailing \\n\",\nbut then I realized that\nit's exactly use of that ANSI-C quoting feature\nwhich makes that \\n newline be (non-)interpreted correctly here,\nand it truly works.\n\nThank you for a fast and well-inform{ed|ing} response!\n\nNow there's only one question remaining:\ndo we simply take this as a documentation-supplied-by-mailing-list item ;-),\nor should certain parts of the parse-rev :/ documentation\nbe improved in a certain manner?\n\n\nNo, there's another one:\nthis syntax seems to be (as indicated) indeed bash-specific,\nsince a short dash test script (POSIX):\n#!/usr/bin/dash\n\ngit rev-parse $':/^My commit\\n'\n\nsimply prints a\n$:/^My commit\\n\nresult,\nand no amount of syntax fiddling\nsucceeded in getting the correct commit result on dash.\n\nWell, since that \\n simply *is* a newline\n(see also\nhttp://unix.stackexchange.com/questions/155367/when-to-use-bash-ansi-c-style-escape-e-g-n ),\na successful way to encode it in dash (all non-bash shells?) is:\n\ngit rev-parse :/'^My commit\n'\n\ni.e. with an *actual* newline.\n\n\nBTW, as a (albeit weak) former m68k architecture user,\nthank you for your efforts!\n\nAndreas Mohr\n"}]}