Re: [PATCH/RFC] Use regex for :/ matching

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 3, 2007, 18:17 UTC
Message-ID: <7vbq97iqxd.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071203173022.GA19219@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> On Mon, Dec 03, 2007 at 10:55:15AM +0000, Johannes Schindelin wrote:
>
>> Except that I did not support ".." (does yours?), _and_ that my patch is 
>> not as nice as yours.
>
> No, I didn't. I'm not sure it is sane, since :/ can contain free-form
> text (and with a regex, .. is not that unlikely). And you can always do
> git-log --not :/foo :/bar
>
>> But then, my patch also works when save_commit_buffer == 0.  But I can 
>> refactor this into its own patch, since it really is a separate issue.
>
> Agreed.

What I found mildly irritating in the current syntax (and that is the primary reason why I use it rarely) is that there is no way to tell it to dig from a particular ref (e.g. "on master branch, find the latest commit whose title matches this string").

For "git-log", you can do "git log master --grep=string -1" to emulate this, and it extends to "git log maint..master --grep=string" to limit the revision ranges and "find all not just latest" very naturally.

Also once we start to talk about supporting "ranges", I suspect the semantics becomes fuzzier, because ":/" is defined as an extended SHA-1 expression that resolves to a single commit. ":/A..:/B" is probably unneeded as you can always say "^:/B :/A", but making ":/A" (we need an extended syntax to differentiate from the singleton case we currently have) to mean "all the commits that match this pattern" is something people might be interested to see. Unfortunately, that does not define a revision range operator but a operator that gives back set of commits that are not consecutive, primarily good for giving to nothing but "git show", and again "git log --grep" would emulate it just as well.

So in short:

 * I do not think extending it to mean a set of commits (with some
   definition of how the set is computed) is a good idea.  It can stay
   "name one commit that matches this string" without losing usefulness,
   and I think it should;

 * The definition of the "match" can be tweaked and introducing regexp
   might be a good way;

 * The definition of the "match" may become more useful if we can limit
   which refs to dig from.