{"thread":{"id":"39788","subject":"refspecs with '*' as part of pattern","startedAt":"2015-07-06T18:31:42Z","lastAt":"2015-07-07T23:20:33Z","messageCount":8,"participants":["Jacob Keller","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"265614","messageId":"CA+P7+xoosLG3J5uUVakzwYoxVARs-NH4BJBtsMgw2NB39vyE6A@mail.gmail.com","threadId":"39788","inReplyTo":null,"subject":"refspecs with '*' as part of pattern","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-06T18:31:42Z","receivedAt":"2015-07-06T18:31:42Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"Hi,\n\nI've been looking at the refspecs for git fetch, and noticed that\nglobs are partially supported. I wanted to use something like:\n\nrefs/tags/some-prefix-*:refs/tags/some-prefix-*\n\nas a refspec, so that I can fetch only tags which have a specific\nprefix. I know that I could use namespaces to separate tags, but\nunfortunately, I am unable to fix the tag format. The specific\nrepository in question is also generating several tags which are not\nrelevant to me, in formats that are not really useful for human\nconsumption. I am also not able to fix this less than useful practice.\n\nHowever, I noticed that refspecs only support * as a single component.\nThe match algorithm works perfectly fine, as documented in\nabd2bde78bd9 (\"Support '*' in the middle of a refspec\")\n\nWhat is the reason for not allowing slightly more arbitrary\nexpressions? Obviously no more than one *...\n\nIt seems like the \"strict\" requirements, as in the above commit, but i\nan unable to find what these requirements are, and why they can't\nallow more expressions.\n\nIt's possible that users might not expect it to work, but maybe it\ncould be configured behind an extra option to prevent accidental use?\nI think it's quite intuitive though.\n\nMaybe because it allows some shenanagins to rename tags, but... that's\nreally the user's fault... Another reason for putting this behind an\noption possibly?\n\nPersonally I would like to be able to use this as it allows much more\nfine grained control over what I fetch, and lets me stick with the\nun-namespaced tags which are something I can't change.\n\nIf this isn't something that can be done I would appreciate a good\nexplanation of what it might break and why it's a bad idea...\n\nRegards,\nJake\n"},{"id":"265634","messageId":"xmqqzj38yjpg.fsf@gitster.dls.corp.google.com","threadId":"39788","inReplyTo":"CA+P7+xoosLG3J5uUVakzwYoxVARs-NH4BJBtsMgw2NB39vyE6A@mail.gmail.com","subject":"Re: refspecs with '*' as part of pattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-06T23:01:15Z","receivedAt":"2015-07-06T23:01:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller writes:\n\n> I've been looking at the refspecs for git fetch, and noticed that\n> globs are partially supported. I wanted to use something like:\n>\n> refs/tags/some-prefix-*:refs/tags/some-prefix-*\n>\n> as a refspec, so that I can fetch only tags which have a specific\n> prefix. I know that I could use namespaces to separate tags, but\n> unfortunately, I am unable to fix the tag format. The specific\n> repository in question is also generating several tags which are not\n> relevant to me, in formats that are not really useful for human\n> consumption. I am also not able to fix this less than useful practice.\n>\n> However, I noticed that refspecs only support * as a single component.\n> The match algorithm works perfectly fine, as documented in\n> abd2bde78bd9 (\"Support '*' in the middle of a refspec\")\n>\n> What is the reason for not allowing slightly more arbitrary\n> expressions? Obviously no more than one *...\n\nI cannot seem to be able to find related discussions around that\npatch, so this is only my guess, but I suspect that this is to\ndiscourage people from doing something like:\n\n\trefs/tags/*:refs/tags/foo-*\n\nwhich would open can of worms (e.g. imagine you fetch with that\npathspec and then push with refs/tags/*:refs/tags/* back there;\nwould you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0\ntag?) we'd prefer not having to worry about.\n"},{"id":"265637","messageId":"CA+P7+xqaiKnFs1rThc3RMt=UJT4whmMdE9sBDtstbx6oxx08Xg@mail.gmail.com","threadId":"39788","inReplyTo":"xmqqzj38yjpg.fsf@gitster.dls.corp.google.com","subject":"Re: refspecs with '*' as part of pattern","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-06T23:39:02Z","receivedAt":"2015-07-06T23:39:02Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, Jul 6, 2015 at 4:01 PM, Junio C Hamano wrote:\n> Jacob Keller writes:\n>\n>> What is the reason for not allowing slightly more arbitrary\n>> expressions? Obviously no more than one *...\n>\n> I cannot seem to be able to find related discussions around that\n> patch, so this is only my guess, but I suspect that this is to\n> discourage people from doing something like:\n>\n> refs/tags/*:refs/tags/foo-*\n>\n> which would open can of worms (e.g. imagine you fetch with that\n> pathspec and then push with refs/tags/*:refs/tags/* back there;\n> would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0\n> tag?) we'd prefer not having to worry about.\n>\n>\n>\n\nThat is what I assumed. Would some sort of fetch option you could set\nin gitconfig be acceptable? Or possibly extending code to verify that\nit doesn't do something too silly? Like extend it to verify that the\nper-section path is actually the same?\n\nToday you can get a similar issue with\n\nrefs/tags/*:refs/tags/foo/*\n\nIt just is easier to fix since they're all name-spaced into foo instead.\n\nThe issue I have is that I only want to download specific tag format,\ninstead of all tags.. Maybe there is a better way to handle this?\n\nBasically, the automated build software that my team uses (I don't\nhave a choice here) generates tags like\n\nscm_063015_050528\n\nand then I re-generate human readable tags based on information so\nthey look like\n\ndriver-name-0-16-3\n\nI don't want to ever pull scm_* tags because these are useless. I have\ntried very much to change the behavior of the team running the build\nsoftware, but they refuse to budge (as this software works against\nCVS/SVN etc, and supports some older work, and they don't want to\nspecial case it if they can avoid it).\n\nBasically, all I see in my git tags are useless scm tags, and I want\nto not download them ever. (so that they don't show up as possible\nrefs at all)\n\nIs there a possible better solution to this?\n\nRegards,\nJake\n"},{"id":"265640","messageId":"alpine.LNX.2.00.1507062208580.2241@iabervon.iabervon.org","threadId":"39788","inReplyTo":"xmqqzj38yjpg.fsf@gitster.dls.corp.google.com","subject":"Re: refspecs with '*' as part of pattern","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.iabervon.org","sentAt":"2015-07-07T02:20:24Z","receivedAt":"2015-07-07T02:20:24Z","isPatch":false,"sender":{"key":"barkalow@iabervon.iabervon.org","avatar":null},"body":"On Mon, 6 Jul 2015, Junio C Hamano wrote:\n\n> Jacob Keller writes:\n> \n> > I've been looking at the refspecs for git fetch, and noticed that\n> > globs are partially supported. I wanted to use something like:\n> >\n> > refs/tags/some-prefix-*:refs/tags/some-prefix-*\n> >\n> > as a refspec, so that I can fetch only tags which have a specific\n> > prefix. I know that I could use namespaces to separate tags, but\n> > unfortunately, I am unable to fix the tag format. The specific\n> > repository in question is also generating several tags which are not\n> > relevant to me, in formats that are not really useful for human\n> > consumption. I am also not able to fix this less than useful practice.\n> >\n> > However, I noticed that refspecs only support * as a single component.\n> > The match algorithm works perfectly fine, as documented in\n> > abd2bde78bd9 (\"Support '*' in the middle of a refspec\")\n> >\n> > What is the reason for not allowing slightly more arbitrary\n> > expressions? Obviously no more than one *...\n> \n> I cannot seem to be able to find related discussions around that\n> patch, so this is only my guess, but I suspect that this is to\n> discourage people from doing something like:\n> \n> \trefs/tags/*:refs/tags/foo-*\n> \n> which would open can of worms (e.g. imagine you fetch with that\n> pathspec and then push with refs/tags/*:refs/tags/* back there;\n> would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0\n> tag?) we'd prefer not having to worry about.\n\nThat wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same \nproblem, assuming you didn't set up the push refspec carefully.\n\nI think it was mostly that it would be too easy to accidentally do \nsomething you don't want by having some other character instead of a \nslash, like refs/heads/*:refs/heads-*.\n\nAside from the increased risk of hard-to-spot typos leading to very weird \nbehavior, nothing actually goes wrong; in fact, I've been using git with \nthat check removed for ages because I wanted a refspec like \nrefs/heads/something-*:refs/heads/*. And it works fine as a local patch, \nsince you don't need your refspec handling to interoperate with other \nrepositories.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"265641","messageId":"CA+P7+xofoxdgQUng1N1NpXyALzjjmAYe++GJoA6qD+zUbZk-vg@mail.gmail.com","threadId":"39788","inReplyTo":"alpine.LNX.2.00.1507062208580.2241@iabervon.iabervon.org","subject":"Re: refspecs with '*' as part of pattern","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-07T02:33:19Z","receivedAt":"2015-07-07T02:33:19Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, Jul 6, 2015 at 7:20 PM, Daniel Barkalow\n wrote:\n> On Mon, 6 Jul 2015, Junio C Hamano wrote:\n>\n>> Jacob Keller writes:\n>>\n>> > I've been looking at the refspecs for git fetch, and noticed that\n>> > globs are partially supported. I wanted to use something like:\n>> >\n>> > refs/tags/some-prefix-*:refs/tags/some-prefix-*\n>> >\n>> > as a refspec, so that I can fetch only tags which have a specific\n>> > prefix. I know that I could use namespaces to separate tags, but\n>> > unfortunately, I am unable to fix the tag format. The specific\n>> > repository in question is also generating several tags which are not\n>> > relevant to me, in formats that are not really useful for human\n>> > consumption. I am also not able to fix this less than useful practice.\n>> >\n>> > However, I noticed that refspecs only support * as a single component.\n>> > The match algorithm works perfectly fine, as documented in\n>> > abd2bde78bd9 (\"Support '*' in the middle of a refspec\")\n>> >\n>> > What is the reason for not allowing slightly more arbitrary\n>> > expressions? Obviously no more than one *...\n>>\n>> I cannot seem to be able to find related discussions around that\n>> patch, so this is only my guess, but I suspect that this is to\n>> discourage people from doing something like:\n>>\n>> refs/tags/*:refs/tags/foo-*\n>>\n>> which would open can of worms (e.g. imagine you fetch with that\n>> pathspec and then push with refs/tags/*:refs/tags/* back there;\n>> would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0\n>> tag?) we'd prefer not having to worry about.\n>\n> That wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same\n> problem, assuming you didn't set up the push refspec carefully.\n>\n> I think it was mostly that it would be too easy to accidentally do\n> something you don't want by having some other character instead of a\n> slash, like refs/heads/*:refs/heads-*.\n>\n> Aside from the increased risk of hard-to-spot typos leading to very weird\n> behavior, nothing actually goes wrong; in fact, I've been using git with\n> that check removed for ages because I wanted a refspec like\n> refs/heads/something-*:refs/heads/*. And it works fine as a local patch,\n> since you don't need your refspec handling to interoperate with other\n> repositories.\n>\n> -Daniel\n> *This .sig left intentionally blank*\n\n\nWhich is why I suggested a patch that adds this behavior conditionally\nand only for fetch. This way you don't have to use a local patch, and\nit wouldn't hit normal users. Ideally we can add a flag that only\nenables it for refspecs that don't interoperate.\n\nDoes this seem ok? If so I will go ahead and try to work up a patch\n\nRegards,\nJake\n"},{"id":"265653","messageId":"CA+P7+xo=WyyJncO0Q3KMO+6kgs-g1i9KNRTtGw865Je=X5U=_g@mail.gmail.com","threadId":"39788","inReplyTo":"CA+P7+xofoxdgQUng1N1NpXyALzjjmAYe++GJoA6qD+zUbZk-vg@mail.gmail.com","subject":"Re: refspecs with '*' as part of pattern","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-07T07:22:38Z","receivedAt":"2015-07-07T07:22:38Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, Jul 6, 2015 at 7:33 PM, Jacob Keller wrote:\n> On Mon, Jul 6, 2015 at 7:20 PM, Daniel Barkalow\n> wrote:\n>> On Mon, 6 Jul 2015, Junio C Hamano wrote:\n>>\n>>> Jacob Keller writes:\n>>>\n>>> > I've been looking at the refspecs for git fetch, and noticed that\n>>> > globs are partially supported. I wanted to use something like:\n>>> >\n>>> > refs/tags/some-prefix-*:refs/tags/some-prefix-*\n>>> >\n>>> > as a refspec, so that I can fetch only tags which have a specific\n>>> > prefix. I know that I could use namespaces to separate tags, but\n>>> > unfortunately, I am unable to fix the tag format. The specific\n>>> > repository in question is also generating several tags which are not\n>>> > relevant to me, in formats that are not really useful for human\n>>> > consumption. I am also not able to fix this less than useful practice.\n>>> >\n>>> > However, I noticed that refspecs only support * as a single component.\n>>> > The match algorithm works perfectly fine, as documented in\n>>> > abd2bde78bd9 (\"Support '*' in the middle of a refspec\")\n>>> >\n>>> > What is the reason for not allowing slightly more arbitrary\n>>> > expressions? Obviously no more than one *...\n>>>\n>>> I cannot seem to be able to find related discussions around that\n>>> patch, so this is only my guess, but I suspect that this is to\n>>> discourage people from doing something like:\n>>>\n>>> refs/tags/*:refs/tags/foo-*\n>>>\n>>> which would open can of worms (e.g. imagine you fetch with that\n>>> pathspec and then push with refs/tags/*:refs/tags/* back there;\n>>> would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0\n>>> tag?) we'd prefer not having to worry about.\n>>\n>> That wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same\n>> problem, assuming you didn't set up the push refspec carefully.\n>>\n>> I think it was mostly that it would be too easy to accidentally do\n>> something you don't want by having some other character instead of a\n>> slash, like refs/heads/*:refs/heads-*.\n>>\n>> Aside from the increased risk of hard-to-spot typos leading to very weird\n>> behavior, nothing actually goes wrong; in fact, I've been using git with\n>> that check removed for ages because I wanted a refspec like\n>> refs/heads/something-*:refs/heads/*. And it works fine as a local patch,\n>> since you don't need your refspec handling to interoperate with other\n>> repositories.\n>>\n>> -Daniel\n>> *This .sig left intentionally blank*\n>\n>\n> Which is why I suggested a patch that adds this behavior conditionally\n> and only for fetch. This way you don't have to use a local patch, and\n> it wouldn't hit normal users. Ideally we can add a flag that only\n> enables it for refspecs that don't interoperate.\n>\n> Does this seem ok? If so I will go ahead and try to work up a patch\n>\n> Regards,\n> Jake\n\nI am working up a patch to try and get this configurable. I'll\nhopefully send it out tomorrow morning sometime.\n\nRegards,\nJake\n"},{"id":"265753","messageId":"xmqqbnfo3paa.fsf@gitster.dls.corp.google.com","threadId":"39788","inReplyTo":"alpine.LNX.2.00.1507062208580.2241@iabervon.iabervon.org","subject":"Re: refspecs with '*' as part of pattern","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-07T16:28:45Z","receivedAt":"2015-07-07T16:28:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On Mon, 6 Jul 2015, Junio C Hamano wrote:\n>\n>> I cannot seem to be able to find related discussions around that\n>> patch, so this is only my guess, but I suspect that this is to\n>> discourage people from doing something like:\n>> \n>> \trefs/tags/*:refs/tags/foo-*\n>> \n>> which would open can of worms (e.g. imagine you fetch with that\n>> pathspec and then push with refs/tags/*:refs/tags/* back there;\n>> would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0\n>> tag?) we'd prefer not having to worry about.\n>\n> That wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same \n> problem, assuming you didn't set up the push refspec carefully.\n\nThanks, I was wondering where you were ;-) Nice to hear from you\nfrom time to time.\n\n> I think it was mostly that it would be too easy to accidentally do \n> something you don't want by having some other character instead of a \n> slash, like refs/heads/*:refs/heads-*.\n\nHmm, interesting thought.\n\nBut refs/heads/*:refs/heade/* would not be saved, so I do not think\nthat is it, either.\n"},{"id":"265786","messageId":"CA+P7+xoobt_W11ruGVmJ0hzTEqNcdqk=cgRUAuYqSchPJcTsrw@mail.gmail.com","threadId":"39788","inReplyTo":"xmqqbnfo3paa.fsf@gitster.dls.corp.google.com","subject":"Re: refspecs with '*' as part of pattern","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-07T23:20:33Z","receivedAt":"2015-07-07T23:20:33Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Jul 7, 2015 at 9:28 AM, Junio C Hamano wrote:\n> Daniel Barkalow writes:\n>\n>> On Mon, 6 Jul 2015, Junio C Hamano wrote:\n>>\n>>> I cannot seem to be able to find related discussions around that\n>>> patch, so this is only my guess, but I suspect that this is to\n>>> discourage people from doing something like:\n>>>\n>>> refs/tags/*:refs/tags/foo-*\n>>>\n>>> which would open can of worms (e.g. imagine you fetch with that\n>>> pathspec and then push with refs/tags/*:refs/tags/* back there;\n>>> would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0\n>>> tag?) we'd prefer not having to worry about.\n>>\n>> That wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same\n>> problem, assuming you didn't set up the push refspec carefully.\n>\n> Thanks, I was wondering where you were ;-) Nice to hear from you\n> from time to time.\n>\n>> I think it was mostly that it would be too easy to accidentally do\n>> something you don't want by having some other character instead of a\n>> slash, like refs/heads/*:refs/heads-*.\n>\n> Hmm, interesting thought.\n>\n> But refs/heads/*:refs/heade/* would not be saved, so I do not think\n> that is it, either.\n\nIn this case, I'm more in favor of just allowing these refs because\nthe user already has to manually change the refspecs, which is\nsomething many users will never do. I also think that given the above\ncomments, we're not really protecting the user from anything extra...\naside from adding more pain because the globs don't work as expected.\n\nI did submit a patch (from my @intel.com address since I can't seem to\nget git-for-windows to send from my home computer) but I am willing to\nre-work to drop the setting if everyone is ok with that...\n\nThoughts?\n\nRegards,\nJake\n"}]}