Re: [RFC] Refspec patterns with * in the middle

From: David Kastrup <dak@gnu.org>
Date: Mar 3, 2009, 16:25 UTC
Message-ID: <863aduo9o3.fsf@lola.quinscape.zz>
In-Reply-To: <7vsklvlcyy.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> 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.
>
> Isn't this just getting more and more insane?  Is this really worth
> supporting, I have to wonder...
>
>> 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.
>
> Well, "?" is not allowed exactly because it often is used to match a
> single character by things like for-each-ref.

Let me present a use case where the current matching rules have changed working well at some point of time.

We have a product called dsp which sits in Subversion under the top server repository as

dsp/{trunk,branches,tags}

Then we have projects that have a structure including

projekte/some-project/{trunk,branches,tags}/dsp

which usually is an external link to dsp/trunk. However, sometimes a project needs its own local variations of dsp, in which case projekte/some-project/trunk/dsp becomes a properly populated copy of dsp/trunk.

Now in git, I want to track those non-externals as branches of the dsp checkout: that way I get cherry-picking and merging and stuff like that. To have this work out, I need to have the dsp git project pulling stuff from any projekte/some-project/trunk/dsp as a branch called some-project.

I had a git-svn configuration at one point of time that did that, but the matching rules have changed since then.

So in this case, the existing Subversion structure (which makes quite good sense) makes wildcards in non-terminal positions desirable.

-- 
David Kastrup