Re: [BUG] git rev-parse :/ "regex" syntax not really regex?
On Sun, Apr 17, 2016 at 04:10:28PM +0200, Andreas Schwab wrote: > Andreas Mohrwrites: > > > Unless I happened to misunderstand git's regex flavour, or something else... > > (hmm, perhaps it's a try-match-single-line vs. multi-line content issue, > > which perhaps does not work by specifying the trailing $) > > This is exactly the difference. git log --grep matches individual lines > (like grep), whereas :/ matches against the whole commit message > including embedded (and trailing) newlines, and $ doesn't match an > embedded newline. Thus to address the second commit in your example you > have to use $':/^My commit\n' (using bash's ANSI-C quoting feature). At first I thought "no way, I already did try trailing \n", but then I realized that it's exactly use of that ANSI-C quoting feature which makes that \n newline be (non-)interpreted correctly here, and it truly works. Thank you for a fast and well-inform{ed|ing} response! Now there's only one question remaining: do we simply take this as a documentation-supplied-by-mailing-list item ;-), or should certain parts of the parse-rev :/ documentation be improved in a certain manner? No, there's another one: this syntax seems to be (as indicated) indeed bash-specific, since a short dash test script (POSIX): #!/usr/bin/dash git rev-parse $':/^My commit\n' simply prints a $:/^My commit\n result, and no amount of syntax fiddling succeeded in getting the correct commit result on dash. Well, since that \n simply *is* a newline (see also http://unix.stackexchange.com/questions/155367/when-to-use-bash-ansi-c-style-escape-e-g-n ), a successful way to encode it in dash (all non-bash shells?) is: git rev-parse :/'^My commit ' i.e. with an *actual* newline. BTW, as a (albeit weak) former m68k architecture user, thank you for your efforts! Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] git rev-parse :/ "regex" syntax not really regex?
Andreas Mohrwrites: > Unless I happened to misunderstand git's regex flavour, or something else... > (hmm, perhaps it's a try-match-single-line vs. multi-line content issue, > which perhaps does not work by specifying the trailing $) This is exactly the difference. git log --grep matches individual lines (like grep), whereas :/ matches against the whole commit message including embedded (and trailing) newlines, and $ doesn't match an embedded newline. Thus to address the second commit in your example you have to use $':/^My commit\n' (using bash's ANSI-C quoting feature). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] git rev-parse :/ "regex" syntax not really regex?
Hello all, I just wanted to shortly mention that to me it seems that while git help rev-parse says :/, e.g. :/fix nasty bug 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 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 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 can use e.g. :/^foo. , the supported syntax seems to be decidedly not really regex, as opposed to git log --grep Creating a minimal reproducing repo sample with e.g. a dummy commit series of the following commit titles: My commit last My commit My commit first and doing searches via git rev-parse :/'^My commi\w' git rev-parse :/'^My commit$' git rev-parse :/'^My commit' git log --grep='^My commit$' --format=%H < that one seems to work fully reliably will yield surprising results (returning most recent commit rather than commit title exact-match one), and no amount of fiddling with various regex flavour syntax deviations managed to fix it for me. Unless I happened to misunderstand git's regex flavour, or something else... (hmm, perhaps it's a try-match-single-line vs. multi-line content issue, which perhaps does not work by specifying the trailing $) $ git --version git version 2.5.5 (same irritating behaviour also encountered on some older version, perhaps 2.0/2.1 range) If this bug is confirmed, then I could suggest two variants: - fix rev-parse's handling of :/ to actually do the correct thing, if easily possible - simply fix rev-parse's docs to correctly indicate that unfortunately it is NOT fully regex capable, and ensure also having added a reference to the (much?) more reliably working git log --grep. If this bug is not confirmed, then the question would be what kind of potential documentation / usability weaknesses successfully managed to lead me astray and thus would need to be fixed. Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html