[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
       :/<text>, 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

Andreas Mohr <andi@lisas.de> writes:

This is exactly the difference. git log --grep matches individual lines (like grep), whereas :/<regexp> 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.

On Sun, Apr 17, 2016 at 04:10:28PM +0200, Andreas Schwab wrote:

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