Re: [RFD} Use regex's in :/ revision naming machinery

From: Yann Dirson <dirson@bertin.fr>
Date: Apr 6, 2010, 07:02 UTC
Message-ID: <20100406090200.46a7c66b@chalon.bertin.fr>

Let's step in as a user of the feature :)

I started to use :/ very recently, and found it very convenient for my particular use. I'm running a script which takes a treeish as argument, which I regularly run on a dev branch on which I am editing the commits regularly - that is, the commit message rarely change, but the sha1's do. Then once I have a working :/ expr, I can just reuse the line from shell history, saving typing.

Also, for composing the :/ expression, I make use of "git slog|head" (slog being an alias of mostly "git log --pretty=oneline"), which helps figuring out a prefix string that does not require too much keystrokes. There again, it is a gain compared to grabbing the mouse to cut+paste a sha1.

Junio wrote:

>I also happen to think that the current ':/' is more or less useless
>because you cannot tell it to start digging from only these branches,
>and it becomes dice-throwing which commit it would find.

Now what I found really strange, is that the ":" in :/ would not act as it does in the [<treeish>]:<file> syntax. Allowing to use [<treeish>]:/<regexp> would not only make it more useful, but also more consistent with that other syntax.

>A related but a larger issue is that I suspect this "two-dot" would not
>work, as the syntax looks for "Merge branch 'slabh'.." (two-dot taken
>literally).

Right there is a problem here - even if it works when you mean ".." as the range separator, it makes it hard to specify a ".." search pattern.

What about using ":/pattern/" as a syntax instead ? That would also be close to other familiar stuff - although it would now require quoting a "/" to include it in the search pattern...

Another issue would be to (de)activate regexp processing (as compared to just substring or leading-substring behaviour). Maybe we could use sed-like trailing modifiers for this - eg. if regexp is made the default, ":/obj.c/f" would not match "object". This would also give us provision to add classical pattern modifiers like /i, and at 1st sight would still be unambiguous wrt the .. separator.

Does that make sense ?

-- 
Yann