Daniel Barkalow [off-list ref] 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.
Junio C Hamano [off-list ref] writes:
Daniel Barkalow [off-list ref] writes:
quoted
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...
quoted
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