Re: [RFC] Refspec patterns with * in the middle
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Mar 2, 2009, 23:00 UTC
- Message-ID
- <alpine.LNX.1.00.0903021746140.19665@iabervon.org>
- In-Reply-To
- <7v1vtfmtwj.fsf@gitster.siamese.dyndns.org>
On Mon, 2 Mar 2009, Junio C Hamano wrote:
Show 32 quoted lines
> Jay Soffian <jaysoffian@gmail.com> writes: > > > On Mon, Mar 2, 2009 at 1:25 PM, Daniel Barkalow <barkalow@iabervon.org> wrote: > >>> But the following is not: > >>> > >>> - foo/bar*/baz > >>> > >>> IOW, '*' can only appear as a non-terminating symbol if it is bounded > >>> by '/' on each side. > >> > >> You have my criterion right, but I want that to be valid, but only match > >> things like "foo/bar-something/baz", not "foo/bar-a/b/baz". > > > > Ah, that makes sense. Perhaps use "**" to mean matching across path > > components which is what rsync does: > > > > o a '*' matches any non-empty path component (it stops at slashes). > > o use '**' to match anything, including slashes. > > > > ? > > I personally do not think that makes much sense (and I find ** ugly, too). > > We traditionally supported '*' only at the end, and it always has meant > "match through the end, including slashes". > > Requiring 'match including slashes' to be spelled as '**' only when it is > not at the end is unnecessarily confusing. > > Is there a valid use case when * wants to match across directory > boundaries when it is not at the end? I offhand do not think of a sane > one.
Maybe:
/refs/imported/$GROUP/$USER/project -> $GROUP/$USER
or
/refs/imported/sandbox/$USER/$TOPIC/project -> $USER/$TOPIC
The issue, in my case, is importing from a system where branches contain projects instead of projects containing branches (and everything is a single namespace). So I want to match an insane (for us) LHS with a sane RHS to get stuff into reasonable shape. I don't really care about any patterns where the branch identifier is multiple components, but I wouldn't be surprised if somebody did.
Oh, and it looks like "?" is reserved and currently unused, so we could have * match one or more full path components, and ? match partial path components.
-Daniel *This .sig left intentionally blank*