[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