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
--
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

Reply via email to