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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux