Re: [RFC] Using gitrevisions :/search style with other operators

From: Kevin Ballard <kevin@sb.org>
Date: Nov 8, 2010, 22:11 UTC
Message-ID: <4F75AA0C-B68A-4ABB-B67A-D7F62D989655@sb.org>
In-Reply-To: <7vpqufpr7f.fsf@alter.siamese.dyndns.org>

On Nov 8, 2010, at 11:09 AM, Junio C Hamano wrote:

Show 11 quoted lines

> Kevin Ballard <kevin@sb.org> writes:
> 
>> There is one operator that doesn't allow this at all, and that's the commit
>> message search (e.g. :/foo). Every character after the :/ is taken to be
>> part of the regular expression. This is rather unfortunate as it prevents me
>> from doing something like :/foo^ to refer to the parent of the matching commit.
>> 
>> Does anybody have any opinions on changing this operator?
> 
> If you mean to change what ":/Merge branch 'kb/blame-author-email'" means,
> and make my scripts suddenly start breaking, I would be moderately unhappy.

Ah yes, I suppose you do have a common case it would break.

Show 11 quoted lines

> It is fine if we can enhance the extended SHA-1 vocabulary by introducing
> a syntax that used to be illegal, hence there is no chance somebody was
> using it for other purposes.
> 
> I wonder if we can introduce something like ':( ... )' to group things.
> E.g.
> 
>    $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2'
> 
> I haven't visited the particular codepath for some time, so I don't know
> offhand how involved the change would be, though.

Interesting idea. It certainly solves the problem of being able to embed it within other operations (though you do then have to worry about escaping any embedded close-parens in the search), though it does mean my suggestion for being able to select the 2nd (or nth) match won't work. When I have the time I'll start taking a look at the code.

Any comments on my suggestion to specify the ref to search from, e.g. origin/pu:/"Merge 'kb/blame-author-email'"? As I stated before, I believe this syntax is currently-unused (as it is interpreted as a file lookup, but file paths starting with / will never resolve to anything in testing), but I want to make sure I'm not overlooking something.

-Kevin Ballard