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

1 messages from 2010-04-06 to 2010-04-06. Participants: Yann Dirson.
Thread: https://gitlist.dev/t/23351

## Yann Dirson, 2010-04-06 07:02

Subject: Re: [RFD} Use regex's in :/ revision naming machinery
Message-ID: <20100406090200.46a7c66b@chalon.bertin.fr>
URL: https://gitlist.dev/e/20100406090200.46a7c66b%40chalon.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

```