[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