[BUG] git rev-parse :/ "regex" syntax not really regex?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]