{"thread":{"id":"54568","subject":"support comma-separated fetch specs list?","startedAt":"2020-11-04T03:11:57Z","lastAt":"2020-11-09T22:45:36Z","messageCount":4,"participants":["ryenus","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"409063","messageId":"CAKkAvaxrG0aYw-wo_WW7zSkX=mjU8ABgXGbbPCFOhMBa4WTJ+Q@mail.gmail.com","threadId":"54568","inReplyTo":null,"subject":"support comma-separated fetch specs list?","fromName":"ryenus","fromEmail":"ryenus@gmail.com","sentAt":"2020-11-04T03:11:42Z","receivedAt":"2020-11-04T03:11:57Z","isPatch":false,"sender":{"key":"ryenus@gmail.com","avatar":"https://avatars.githubusercontent.com/u/610161?v=4"},"body":"It's nice to have negative ref spec support with 2.29 release, so now\nwe can have\n\n```\n[remote \"origin\"]\n fetch = +refs/heads/*:refs/remotes/origin/*\n fetch = ^refs/heads/gh-pages\n```\n\nWhat about having all the fetch specs put together in one comma-separated list?\nLike this:\n\n```\n[remote \"origin\"]\n fetch = +refs/heads/*:refs/remotes/origin/*,^refs/heads/gh-pages\n```\n\nThanks\n"},{"id":"409064","messageId":"xmqq1rh9ptka.fsf@gitster.c.googlers.com","threadId":"54568","inReplyTo":"CAKkAvaxrG0aYw-wo_WW7zSkX=mjU8ABgXGbbPCFOhMBa4WTJ+Q@mail.gmail.com","subject":"Re: support comma-separated fetch specs list?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-11-04T05:41:41Z","receivedAt":"2020-11-04T05:41:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ryenus writes:\n\n> It's nice to have negative ref spec support with 2.29 release, so now\n> we can have\n>\n> ```\n> [remote \"origin\"]\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> fetch = ^refs/heads/gh-pages\n> ```\n>\n> What about having all the fetch specs put together in one comma-separated list?\n> Like this:\n>\n> ```\n> [remote \"origin\"]\n> fetch = +refs/heads/*:refs/remotes/origin/*,^refs/heads/gh-pages\n> ```\n\nI thought comma was a valid character that you can have in refnames,\nso no, I do not think it would fly without breaking existing users.\n\nWhat problem are you trying to solve?\n"},{"id":"409319","messageId":"CAKkAvawVbyTPxDFQMEJMh+dzgQ_C0PXtbQKMo8xMNjgL_buGng@mail.gmail.com","threadId":"54568","inReplyTo":"xmqq1rh9ptka.fsf@gitster.c.googlers.com","subject":"Re: support comma-separated fetch specs list?","fromName":"ryenus","fromEmail":"ryenus@gmail.com","sentAt":"2020-11-07T10:11:02Z","receivedAt":"2020-11-07T10:11:18Z","isPatch":false,"sender":{"key":"ryenus@gmail.com","avatar":"https://avatars.githubusercontent.com/u/610161?v=4"},"body":"On Wed, 4 Nov 2020 at 13:41, Junio C Hamano wrote:\n>\n> ryenus writes:\n>\n> > It's nice to have negative ref spec support with 2.29 release, so now\n> > we can have\n> >\n> > ```\n> > [remote \"origin\"]\n> > fetch = +refs/heads/*:refs/remotes/origin/*\n> > fetch = ^refs/heads/gh-pages\n> > ```\n> >\n> > What about having all the fetch specs put together in one comma-separated list?\n> > Like this:\n> >\n> > ```\n> > [remote \"origin\"]\n> > fetch = +refs/heads/*:refs/remotes/origin/*,^refs/heads/gh-pages\n> > ```\n>\n> I thought comma was a valid character that you can have in refnames,\n> so no, I do not think it would fly without breaking existing users.\n>\n> What problem are you trying to solve?\n\nI guess the problem is mainly about intuition? Since comma-separated\nlists are everywhere.\n\nPersonally I never thought about using comma in refnames, or even knew\nit's allowed.\n\nWell, now I know because, after skimming through the 2.29 release notes,\nI tried out the negative refspec feature in a repo where I'd like to\nexclude the gh-pages branch. But somehow I appended a comma and the\nnegative refspec to the existing fetch line, and expected it to work,\nthen, oops, I got dozens of those refnames with commas, and had to go\ninside the .git dir and managed the clean up all the mess. And that's\nfor sure and nice and hard lesson :-)\n\nMaybe the cause is also my ignorance or lack of carefulness to read the\ndocs, but searching for \"comma separated list\" in Git manual would\nreturn hundreds of results:\nhttps://www.google.com/search?q=%22comma+separated%22+list+site%3Agit-scm.com\n\nSo I guess it's fair to expect it to work in the fetch spec as well?\n"},{"id":"409430","messageId":"xmqqsg9i9mk4.fsf@gitster.c.googlers.com","threadId":"54568","inReplyTo":"CAKkAvawVbyTPxDFQMEJMh+dzgQ_C0PXtbQKMo8xMNjgL_buGng@mail.gmail.com","subject":"Re: support comma-separated fetch specs list?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-11-09T22:45:31Z","receivedAt":"2020-11-09T22:45:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ryenus writes:\n\n> Maybe the cause is also my ignorance or lack of carefulness to read the\n> docs, but searching for \"comma separated list\" in Git manual would\n> return hundreds of results:\n> https://www.google.com/search?q=%22comma+separated%22+list+site%3Agit-scm.com\n>\n> So I guess it's fair to expect it to work in the fetch spec as well?\n\nI doubt it.\n\nThe contents of these \"comma separated list\" are taken from a fixed\nvocabulary and not from unbounded set of things the end-user can\nfreely come up with that allows a comma as part of values.\n\nIn other words, \"--option=ours,theirs\" may make sense only because\nwe control the vocabulary 'common', 'ours', and 'theirs', and we\nmake sure the vocabulary does not contain any word with comma in it.\n\nWhen somebody adds a new option, we try hard during the review not\nto allow \"--option=thing1,thing2,thing3\" as the syntax we give at\nthe UI level where thing$n are end-user controlled values, because\nthat would rob end-users from the option of having a comma in their\nthing$n (for whatever reason). Certain kind of things naturally do\nnot make sense to contain comma in them (e.g. list of numbers, for\nexample) and we may allow end-user controlled input as part of a\ncomma separated tuple, and when the tuple has a fixed length whose\nsize will never change, we may allow end-user controlled thing as\nthe last element of such a comma-separated tuple, but extending that\nto refspec, pathspec, etc. is a bit of stretch, I would have to say.\n\n\n\n"}]}