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

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

[Andreas Mohr]

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

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

[Andreas Schwab]

Andreas Mohr <andi@lisas.de> writes:

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

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.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Andreas Mohr]

On Sun, Apr 17, 2016 at 04:10:28PM +0200, Andreas Schwab wrote:
> Andreas Mohr <andi@lisas.de> writes:
> 
> > 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 $)
> 
> 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).

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