{"thread":{"id":"18083","subject":"[RFC] Refspec patterns with * in the middle","startedAt":"2009-03-01T23:42:34Z","lastAt":"2009-03-03T16:25:48Z","messageCount":12,"participants":["Daniel Barkalow","Jay Soffian","Junio C Hamano","David Kastrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106659","messageId":"alpine.LNX.1.00.0903011820590.19665@iabervon.org","threadId":"18083","inReplyTo":null,"subject":"[RFC] Refspec patterns with * in the middle","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-01T23:42:34Z","receivedAt":"2009-03-01T23:42:34Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"I've got an annoying repository where all of the branches upstream[*] have \nnames, for a project \"my-proj\" like:\n\nsome/constant/stuff/$VERSION/junk/my-proj\n\nI'd like to be able to use refspecs like:\n\n fetch = some/constant/stuff/*/junk/my-proj:refs/remotes/origin/*\n\nI've written an implementation (which mainly involved having only one \nplace do the matching and replacement for pattern refspecs, and then \nmaking that one place a little more clever), so that's not hard. But we \ncurrently prohibit refspecs like this, and I think we may want to prohibit \nsome patterns of this general form, in order to keep typos from doing \nsurprising things.\n\nMy use case is actually, more precisely:\n\nsome/constant/stuff/$PROJ-$NUMBER/junk/my-proj\n\nWhere $NUMBER is the version number, and $PROJ is usually, but not quite \nalways \"my-proj\"; the exception being that it might be effectively a \nsuperproject. So I'd like to have:\n\n fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*\n\nBut I can live with remote branches like \"my-proj-2.4\" instead of \"2.4\".\n\nI think it would make sense, and limit typo damage, to say that the * can \nonly expand to something with a '/' in it if the star has a slash or the \nend of the string on each side.\n\nWhat are other people's thoughts? Should I have a config option for how \nflexible matching is permitted? Any particular constraints I should have \nin general?\n\n[*]\n(This is actually a Perforce upstream, but I want to keep the mapping from \nPerforce into git simple and not grow another pattern-matching format, so \nI'm just copying Perforce paths as ref names, and then I want the match \nthem with the usual code)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"106698","messageId":"76718490903020454j5b787094j1f904a72178a9024@mail.gmail.com","threadId":"18083","inReplyTo":"alpine.LNX.1.00.0903011820590.19665@iabervon.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-03-02T12:54:19Z","receivedAt":"2009-03-02T12:54:19Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Mar 1, 2009 at 6:42 PM, Daniel Barkalow wrote:\n> I've got an annoying repository where all of the branches upstream[*] have\n> names, for a project \"my-proj\" like:\n>\n> some/constant/stuff/$VERSION/junk/my-proj\n>\n> I'd like to be able to use refspecs like:\n>\n>  fetch = some/constant/stuff/*/junk/my-proj:refs/remotes/origin/*\n>\n> I've written an implementation (which mainly involved having only one\n> place do the matching and replacement for pattern refspecs, and then\n> making that one place a little more clever), so that's not hard. But we\n> currently prohibit refspecs like this, and I think we may want to prohibit\n> some patterns of this general form, in order to keep typos from doing\n> surprising things.\n>\n> My use case is actually, more precisely:\n>\n> some/constant/stuff/$PROJ-$NUMBER/junk/my-proj\n>\n> Where $NUMBER is the version number, and $PROJ is usually, but not quite\n> always \"my-proj\"; the exception being that it might be effectively a\n> superproject. So I'd like to have:\n>\n>  fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*\n>\n> But I can live with remote branches like \"my-proj-2.4\" instead of \"2.4\".\n>\n> I think it would make sense, and limit typo damage, to say that the * can\n> only expand to something with a '/' in it if the star has a slash or the\n> end of the string on each side.\n\nThat seems more confusing that just saying: '*' matches everything but\nthe path separator ('/'), and whatever it matches on the LHS of the\n':' is what it expands to on the RHS. I'm not sure how a typo would\ndamage anything, but this could always be enabled with\ncore.refspec.glob_anywhere or some such.\n\nI think regex support is too much:\n\n fetch = some/constant/stuff/(my-proj-[^/]*)/junk/my-proj:refs/remotes/origin/\\1\n\n(Which in a git config, I think may need a double-backslash, but I\nforget what the config parser does.)\n\nj.\n"},{"id":"106712","messageId":"7viqmrn98i.fsf@gitster.siamese.dyndns.org","threadId":"18083","inReplyTo":"alpine.LNX.1.00.0903011820590.19665@iabervon.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-02T17:08:12Z","receivedAt":"2009-03-02T17:08:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> My use case is actually, more precisely:\n>\n> some/constant/stuff/$PROJ-$NUMBER/junk/my-proj\n>\n> Where $NUMBER is the version number, and $PROJ is usually, but not quite \n> always \"my-proj\"; the exception being that it might be effectively a \n> superproject. So I'd like to have:\n>\n> fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*\n\n... and expect \"some/constant/stuff/my-proj-2.5/junk/my-proj\" to be mapped\nto \"refs/remotes/origin/2.5\"? I think it does not look too bad.\n\n> But I can live with remote branches like \"my-proj-2.4\" instead of \"2.4\".\n>\n> I think it would make sense, and limit typo damage, to say that the * can \n> only expand to something with a '/' in it if the star has a slash or the \n> end of the string on each side.\n\nI do not understand what you mean by \"* can only expand to something with\na '/' in it if ...\" part. None of the examples in your message have a\ncase where the asterisk matches across directory boundaries, and I thought\nyou would simply say \"* does not match /\" and be done with that.\n\nWhat scenario do you have in mind that wants to match a slash with an\nasterisk?\n"},{"id":"106718","messageId":"76718490903021001h16009570p7ac8c66a8e8e1f90@mail.gmail.com","threadId":"18083","inReplyTo":"7viqmrn98i.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-03-02T18:01:30Z","receivedAt":"2009-03-02T18:01:30Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 2, 2009 at 12:08 PM, Junio C Hamano wrote:\n> Daniel Barkalow writes:\n>\n>> My use case is actually, more precisely:\n>>\n>> some/constant/stuff/$PROJ-$NUMBER/junk/my-proj\n>>\n>> Where $NUMBER is the version number, and $PROJ is usually, but not quite\n>> always \"my-proj\"; the exception being that it might be effectively a\n>> superproject. So I'd like to have:\n>>\n>>  fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*\n>\n> ... and expect \"some/constant/stuff/my-proj-2.5/junk/my-proj\" to be mapped\n> to \"refs/remotes/origin/2.5\"?  I think it does not look too bad.\n>\n>> But I can live with remote branches like \"my-proj-2.4\" instead of \"2.4\".\n>>\n>> I think it would make sense, and limit typo damage, to say that the * can\n>> only expand to something with a '/' in it if the star has a slash or the\n>> end of the string on each side.\n>\n> I do not understand what you mean by \"* can only expand to something with\n> a '/' in it if ...\" part.  None of the examples in your message have a\n> case where the asterisk matches across directory boundaries, and I thought\n> you would simply say \"* does not match /\" and be done with that.\n>\n> What scenario do you have in mind that wants to match a slash with an\n> asterisk?\n\nI think he means the following are valid:\n\n - foo/bar/*/baz\n - foo/bar/baz/*\n\nBut the following is not:\n\n - foo/bar*/baz\n\nIOW, '*' can only appear as a non-terminating symbol if it is bounded\nby '/' on each side.\n\nj.\n"},{"id":"106719","messageId":"alpine.LNX.1.00.0903021231510.19665@iabervon.org","threadId":"18083","inReplyTo":"7viqmrn98i.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-02T18:22:45Z","receivedAt":"2009-03-02T18:22:45Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 2 Mar 2009, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > My use case is actually, more precisely:\n> >\n> > some/constant/stuff/$PROJ-$NUMBER/junk/my-proj\n> >\n> > Where $NUMBER is the version number, and $PROJ is usually, but not quite \n> > always \"my-proj\"; the exception being that it might be effectively a \n> > superproject. So I'd like to have:\n> >\n> > fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*\n> \n> ... and expect \"some/constant/stuff/my-proj-2.5/junk/my-proj\" to be mapped\n> to \"refs/remotes/origin/2.5\"? I think it does not look too bad.\n\nYeah.\n\n> > But I can live with remote branches like \"my-proj-2.4\" instead of \"2.4\".\n> >\n> > I think it would make sense, and limit typo damage, to say that the * can \n> > only expand to something with a '/' in it if the star has a slash or the \n> > end of the string on each side.\n> \n> I do not understand what you mean by \"* can only expand to something with\n> a '/' in it if ...\" part. None of the examples in your message have a\n> case where the asterisk matches across directory boundaries, and I thought\n> you would simply say \"* does not match /\" and be done with that.\n> \n> What scenario do you have in mind that wants to match a slash with an\n> asterisk?\n\nBackwards compatibility? Currently, refs/heads/*:refs/remotes/origin/* \nwill match refs/heads/js/notes with refs/remotes/origin/js/notes, because \nit simply copies everything after the fixed prefix.\n\nI was assuming that that particular matching is an existing requirement \n(and that you used it regularly to share topic-maintenance work between \nmachines).\n\nSo my idea was that a path component of \"*\" would be able to match \nmultiple levels, while a path component of \"something-*\" or \"*-something\" \ncan only match a single path component that starts or ends with the right \nthing. Looking at it now, I think it might be more sane to use \"%\" for the \nsecond case, and say: \"*\" must be used as a full path component, and \nmatches one or more path components; \"%\" may be used as part of a path \ncomponent, and doesn't match the path separator; you can only use one such \ncharacter, and both sides of the refspec have to agree on which.\n\nI think the problem cases were typos like:\n\nrefs/heads*:refs/remotes/origin/* (used to cause problems)\n\nand\n\nrefs/heads/*:refs/remotes/origin* (gives you the originmaster remote?)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"106720","messageId":"alpine.LNX.1.00.0903021323180.19665@iabervon.org","threadId":"18083","inReplyTo":"76718490903021001h16009570p7ac8c66a8e8e1f90@mail.gmail.com","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-02T18:25:16Z","receivedAt":"2009-03-02T18:25:16Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 2 Mar 2009, Jay Soffian wrote:\n\n> On Mon, Mar 2, 2009 at 12:08 PM, Junio C Hamano wrote:\n> > Daniel Barkalow writes:\n> >\n> >> My use case is actually, more precisely:\n> >>\n> >> some/constant/stuff/$PROJ-$NUMBER/junk/my-proj\n> >>\n> >> Where $NUMBER is the version number, and $PROJ is usually, but not quite\n> >> always \"my-proj\"; the exception being that it might be effectively a\n> >> superproject. So I'd like to have:\n> >>\n> >>  fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*\n> >\n> > ... and expect \"some/constant/stuff/my-proj-2.5/junk/my-proj\" to be mapped\n> > to \"refs/remotes/origin/2.5\"?  I think it does not look too bad.\n> >\n> >> But I can live with remote branches like \"my-proj-2.4\" instead of \"2.4\".\n> >>\n> >> I think it would make sense, and limit typo damage, to say that the * can\n> >> only expand to something with a '/' in it if the star has a slash or the\n> >> end of the string on each side.\n> >\n> > I do not understand what you mean by \"* can only expand to something with\n> > a '/' in it if ...\" part.  None of the examples in your message have a\n> > case where the asterisk matches across directory boundaries, and I thought\n> > you would simply say \"* does not match /\" and be done with that.\n> >\n> > What scenario do you have in mind that wants to match a slash with an\n> > asterisk?\n> \n> I think he means the following are valid:\n> \n> - foo/bar/*/baz\n> - foo/bar/baz/*\n> \n> But the following is not:\n> \n> - foo/bar*/baz\n> \n> IOW, '*' can only appear as a non-terminating symbol if it is bounded\n> by '/' on each side.\n\nYou have my criterion right, but I want that to be valid, but only match \nthings like \"foo/bar-something/baz\", not \"foo/bar-a/b/baz\".\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"106729","messageId":"76718490903021407u215fb769g656a8fdc20e622e5@mail.gmail.com","threadId":"18083","inReplyTo":"alpine.LNX.1.00.0903021323180.19665@iabervon.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-03-02T22:07:31Z","receivedAt":"2009-03-02T22:07:31Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 2, 2009 at 1:25 PM, Daniel Barkalow wrote:\n>> But the following is not:\n>>\n>>  - foo/bar*/baz\n>>\n>> IOW, '*' can only appear as a non-terminating symbol if it is bounded\n>> by '/' on each side.\n>\n> You have my criterion right, but I want that to be valid, but only match\n> things like \"foo/bar-something/baz\", not \"foo/bar-a/b/baz\".\n\nAh, that makes sense. Perhaps use \"**\" to mean matching across path\ncomponents which is what rsync does:\n\n o a '*' matches any non-empty path component (it stops at slashes).\n o use '**' to match anything, including slashes.\n\n?\n\nj.\n"},{"id":"106732","messageId":"7v1vtfmtwj.fsf@gitster.siamese.dyndns.org","threadId":"18083","inReplyTo":"76718490903021407u215fb769g656a8fdc20e622e5@mail.gmail.com","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-02T22:39:24Z","receivedAt":"2009-03-02T22:39:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> On Mon, Mar 2, 2009 at 1:25 PM, Daniel Barkalow wrote:\n>>> But the following is not:\n>>>\n>>>  - foo/bar*/baz\n>>>\n>>> IOW, '*' can only appear as a non-terminating symbol if it is bounded\n>>> by '/' on each side.\n>>\n>> You have my criterion right, but I want that to be valid, but only match\n>> things like \"foo/bar-something/baz\", not \"foo/bar-a/b/baz\".\n>\n> Ah, that makes sense. Perhaps use \"**\" to mean matching across path\n> components which is what rsync does:\n>\n> o a '*' matches any non-empty path component (it stops at slashes).\n> o use '**' to match anything, including slashes.\n>\n> ?\n\nI personally do not think that makes much sense (and I find ** ugly, too).\n\nWe traditionally supported '*' only at the end, and it always has meant\n\"match through the end, including slashes\".\n\nRequiring 'match including slashes' to be spelled as '**' only when it is\nnot at the end is unnecessarily confusing.\n\nIs there a valid use case when * wants to match across directory\nboundaries when it is not at the end? I offhand do not think of a sane\none.\n\nSo, it might make it easiest to understand if we say * usually does not\nmatch slash, except when it is used at the end immediately after a slash,\nin which case it means \"match through the end\".\n"},{"id":"106735","messageId":"76718490903021458s497a04a9p5c81a302cb09666a@mail.gmail.com","threadId":"18083","inReplyTo":"7v1vtfmtwj.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-03-02T22:58:07Z","receivedAt":"2009-03-02T22:58:07Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 2, 2009 at 5:39 PM, Junio C Hamano wrote:\n> I personally do not think that makes much sense (and I find ** ugly, too).\n>\n> We traditionally supported '*' only at the end, and it always has meant\n> \"match through the end, including slashes\".\n\nOh, good point, I had not thought that through very well.\n\n> Requiring 'match including slashes' to be spelled as '**' only when it is\n> not at the end is unnecessarily confusing.\n>\n> Is there a valid use case when * wants to match across directory\n> boundaries when it is not at the end?  I offhand do not think of a sane\n> one.\n>\n> So, it might make it easiest to understand if we say * usually does not\n> match slash, except when it is used at the end immediately after a slash,\n> in which case it means \"match through the end\".\n\nThat seems simple enough.\n\nj.\n"},{"id":"106736","messageId":"alpine.LNX.1.00.0903021746140.19665@iabervon.org","threadId":"18083","inReplyTo":"7v1vtfmtwj.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-02T23:00:57Z","receivedAt":"2009-03-02T23:00:57Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 2 Mar 2009, Junio C Hamano wrote:\n\n> Jay Soffian writes:\n> \n> > On Mon, Mar 2, 2009 at 1:25 PM, Daniel Barkalow wrote:\n> >>> But the following is not:\n> >>>\n> >>>  - foo/bar*/baz\n> >>>\n> >>> IOW, '*' can only appear as a non-terminating symbol if it is bounded\n> >>> by '/' on each side.\n> >>\n> >> You have my criterion right, but I want that to be valid, but only match\n> >> things like \"foo/bar-something/baz\", not \"foo/bar-a/b/baz\".\n> >\n> > Ah, that makes sense. Perhaps use \"**\" to mean matching across path\n> > components which is what rsync does:\n> >\n> > o a '*' matches any non-empty path component (it stops at slashes).\n> > o use '**' to match anything, including slashes.\n> >\n> > ?\n> \n> I personally do not think that makes much sense (and I find ** ugly, too).\n> \n> We traditionally supported '*' only at the end, and it always has meant\n> \"match through the end, including slashes\".\n> \n> Requiring 'match including slashes' to be spelled as '**' only when it is\n> not at the end is unnecessarily confusing.\n> \n> Is there a valid use case when * wants to match across directory\n> boundaries when it is not at the end? I offhand do not think of a sane\n> one.\n\nMaybe:\n\n/refs/imported/$GROUP/$USER/project -> $GROUP/$USER\n\nor\n\n/refs/imported/sandbox/$USER/$TOPIC/project -> $USER/$TOPIC\n\nThe issue, in my case, is importing from a system where branches contain \nprojects instead of projects containing branches (and everything is a \nsingle namespace). So I want to match an insane (for us) LHS with a sane \nRHS to get stuff into reasonable shape. I don't really care about any \npatterns where the branch identifier is multiple components, but I \nwouldn't be surprised if somebody did.\n\nOh, and it looks like \"?\" is reserved and currently unused, so we could \nhave * match one or more full path components, and ? match partial path \ncomponents.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"106740","messageId":"7vsklvlcyy.fsf@gitster.siamese.dyndns.org","threadId":"18083","inReplyTo":"alpine.LNX.1.00.0903021746140.19665@iabervon.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-02T23:30:29Z","receivedAt":"2009-03-02T23:30:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> The issue, in my case, is importing from a system where branches contain \n> projects instead of projects containing branches (and everything is a \n> single namespace). So I want to match an insane (for us) LHS with a sane \n> RHS to get stuff into reasonable shape. I don't really care about any \n> patterns where the branch identifier is multiple components, but I \n> wouldn't be surprised if somebody did.\n\nIsn't this just getting more and more insane? Is this really worth\nsupporting, I have to wonder...\n\n> Oh, and it looks like \"?\" is reserved and currently unused, so we could \n> have * match one or more full path components, and ? match partial path \n> components.\n\nWell, \"?\" is not allowed exactly because it often is used to match a\nsingle character by things like for-each-ref.\n"},{"id":"106873","messageId":"863aduo9o3.fsf@lola.quinscape.zz","threadId":"18083","inReplyTo":"7vsklvlcyy.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Refspec patterns with * in the middle","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2009-03-03T16:25:48Z","receivedAt":"2009-03-03T16:25:48Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Daniel Barkalow writes:\n>\n>> The issue, in my case, is importing from a system where branches contain \n>> projects instead of projects containing branches (and everything is a \n>> single namespace). So I want to match an insane (for us) LHS with a sane \n>> RHS to get stuff into reasonable shape. I don't really care about any \n>> patterns where the branch identifier is multiple components, but I \n>> wouldn't be surprised if somebody did.\n>\n> Isn't this just getting more and more insane? Is this really worth\n> supporting, I have to wonder...\n>\n>> Oh, and it looks like \"?\" is reserved and currently unused, so we could \n>> have * match one or more full path components, and ? match partial path \n>> components.\n>\n> Well, \"?\" is not allowed exactly because it often is used to match a\n> single character by things like for-each-ref.\n\nLet me present a use case where the current matching rules have changed\nworking well at some point of time.\n\nWe have a product called dsp which sits in Subversion under the top\nserver repository as\n\ndsp/{trunk,branches,tags}\n\nThen we have projects that have a structure including\n\nprojekte/some-project/{trunk,branches,tags}/dsp\n\nwhich usually is an external link to dsp/trunk. However, sometimes a\nproject needs its own local variations of dsp, in which case\nprojekte/some-project/trunk/dsp becomes a properly populated copy of\ndsp/trunk.\n\nNow in git, I want to track those non-externals as branches of the dsp\ncheckout: that way I get cherry-picking and merging and stuff like that.\nTo have this work out, I need to have the dsp git project pulling stuff\nfrom any projekte/some-project/trunk/dsp as a branch called\nsome-project.\n\nI had a git-svn configuration at one point of time that did that, but\nthe matching rules have changed since then.\n\nSo in this case, the existing Subversion structure (which makes quite\ngood sense) makes wildcards in non-terminal positions desirable.\n\n-- \nDavid Kastrup\n"}]}