{"thread":{"id":"4098","subject":"Implementing branch attributes in git config","startedAt":"2006-05-07T21:34:19Z","lastAt":"2006-05-11T17:22:27Z","messageCount":75,"participants":["Pavel Roskin","Junio C Hamano","Linus Torvalds","sean","Johannes Schindelin","Daniel Barkalow","Jakub Narebski","Martin Waitz","Martin Langhoff","Nicolas Pitre","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"19665","messageId":"1147037659.25090.25.camel@dv","threadId":"4098","inReplyTo":null,"subject":"Implementing branch attributes in git config","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-07T21:34:19Z","receivedAt":"2006-05-07T21:34:19Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nI have tried to implement branch attributes (more specifically, the\ndefault for git-fetch) in git config. It turns out that the format of\nthe config file is to rigid.\n\nMinuses, underscores, colons and dots are not allowed in the section\nheaders and keys. I can understand that dots should be allowed either\nin the section names or in the key names, but other limitations seem\ntotally unnecessary.\n\nI think a good implementation should allow any characters in the keys,\neven \"=\", because the key can be quoted. Section names may disallow\nsquare brackets and dots.\n\nSuch limitations make it unpractical to use branch names in section or\nkey names. I'd like to have it fixed.\n\nThe only remaining place is values. This means that there should be\nmultiple entries for the same key. While this is allowed, it seems\nquite fragile and inconvenient.\n\nIn particular, git-repo-config leaves the config file locked in the\nregex is wrong:\n\n$ git-repo-config branch.fetch \"master:origin\" +\nInvalid pattern: +\n$ git-repo-config branch.fetch \"master:origin\" +\ncould not lock config file\n\nTo fix it, just add \"close(fd); unlink(lock_file);\" after \"Invalid\npattern\" in config.c.\n\nI don't quite understand what pattern is needed to add an entry. \"foo\"\nseems to work fine, I don't know why.\n\nThat problem with multiple values is that they are quite fragile and\nrequire special options to access them. Since regex is used, dots in\nthe branch names need to be escaped. Probably more escapes are needed.\n\nAnyway, here's the preliminary patch that implements default fetch\nbranches. Unfortunately, it doesn't even come close to the goal of\nhaving per-branch attributes due to the config file limitations.\n\nTo add an entry, use\n\ngit-repo-config branch.fetch \"localbranch:remotebranch\" foo\n\n\nRead the default fetch branch from the config file\n\nFrom: Pavel Roskin \n\n\n---\n\n git-fetch.sh | 21 +++++++++++++++++----\n 1 files changed, 17 insertions(+), 4 deletions(-)\n\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 280f62e..a5ea92b 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -61,12 +61,25 @@ do\n \tshift\n done\n \n+get_config_rem_branch() {\n+\tfetch_branch=origin\n+\tcur_branch=$(expr $(git-symbolic-ref HEAD) : 'refs/heads/\\(.*\\)')\n+\ttest -z \"$cur_branch\" && return\n+\tcur_branch_esc=$(echo $cur_branch | sed 's/\\./\\\\./')\n+\tbranch_map=$(git-repo-config --get branch.fetch \"^$cur_branch_esc:\")\n+\ttest -z \"$branch_map\" && return\n+\trem_branch=$(expr \"$branch_map\" : \"$cur_branch_esc:\\(.*\\)\")\n+\ttest -z \"$rem_branch\" && return\n+\tfetch_branch=\"$rem_branch\"\n+}\n+\n case \"$#\" in\n 0)\n-\ttest -f \"$GIT_DIR/branches/origin\" ||\n-\t\ttest -f \"$GIT_DIR/remotes/origin\" ||\n-\t\t\tdie \"Where do you want to fetch from today?\"\n-\tset origin ;;\n+\tget_config_rem_branch\n+\ttest -f \"$GIT_DIR/branches/$fetch_branch\" ||\n+\t\ttest -f \"$GIT_DIR/remotes/$fetch_branch\" ||\n+\t\t\tdie \"No remote branch \\\"$fetch_branch\\\"\"\n+\tset \"$fetch_branch\" ;;\n esac\n \n remote_nick=\"$1\"\n\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"19667","messageId":"7v4q01jwwg.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"1147037659.25090.25.camel@dv","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-07T22:24:47Z","receivedAt":"2006-05-07T22:24:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> In particular, git-repo-config leaves the config file locked in the\n> regex is wrong:\n>\n> $ git-repo-config branch.fetch \"master:origin\" +\n> Invalid pattern: +\n> $ git-repo-config branch.fetch \"master:origin\" +\n> could not lock config file\n>\n> To fix it, just add \"close(fd); unlink(lock_file);\" after \"Invalid\n> pattern\" in config.c.\n\nI'd give Johannes the first refusal right to deal with this and\nnot touch repo-config.c myself for now, since I suspect I\ntempted him enough to restructure it ;-).\n\n> I don't quite understand what pattern is needed to add an entry. \"foo\"\n> seems to work fine, I don't know why.\n\nI think the value regexp is \"replace the ones that match this\",\nand the convention he came up with is to use \"^$\" to append (see\nsome examples in t/t1300-repo-config.sh).\n\nIn any case, Documentation/git-repo-config.txt mentions\nvalue_regex without explaining what the semantics is. This\nneeds to be fixed, probably like the attached patch.\n\n> That problem with multiple values is that they are quite fragile and\n> require special options to access them. Since regex is used, dots in\n> the branch names need to be escaped. Probably more escapes are needed.\n\nI have a suspicion that using regex while is more powerful and\nexpressive might be a mistake and it would be easier for users\n(both Porcelain and end-users) to use fnmatch() patterns.\n\n> Such limitations make it unpractical to use branch names in section or\n> key names. I'd like to have it fixed.\n\nI thought that is what the \"for blah\" convention is for (BTW\n\"for\" is not a keyword, just a convention).\n\nAlso the syntax is a bit confusing. I initially was confused,\nafter looking at your example:\n\n\t[branch]\n \tfetch = \"localbranch:remotebranch\"\n\nthat the colon separated value was a usual refspec, but it\nisn't. The LHS is the name of the current branch, and RHS is\nthe name of the remotes/ file, which is not a remote _branch_ at\nall. Perhaps something like this is semantically clearer, aside\nfrom names -- I am bad at coming up with them:\n\n\t[branch]\n\t\tdefaultremote = origin for master\n defaultremote = private for test\n\nto mean, \"we use remotes/origin when on master branch by\ndefault\". Also we would want to use remote.origin.{url,fetch}\nconfiguration item as well, so the \"file existence\" check you do\nin this part of the patch is wrong.\n\n> case \"$#\" in\n> 0)\n> -\ttest -f \"$GIT_DIR/branches/origin\" ||\n> -\t\ttest -f \"$GIT_DIR/remotes/origin\" ||\n> -\t\t\tdie \"Where do you want to fetch from today?\"\n> -\tset origin ;;\n> +\tget_config_rem_branch\n> +\ttest -f \"$GIT_DIR/branches/$fetch_branch\" ||\n> +\t\ttest -f \"$GIT_DIR/remotes/$fetch_branch\" ||\n> +\t\t\tdie \"No remote branch \\\"$fetch_branch\\\"\"\n> +\tset \"$fetch_branch\" ;;\n> esac\n\nWe should instead let the existence check do the right thing for\n\"$1\" when it is used; after all the default \"origin\" may not\nexist, and I suspect we do not probably check that (or if we do\nalready, the above check is totally unnecessary).\n\nI haven't thought things through but I have a suspicion that\nget_config_rem_branch might belong to git-parse-remote.sh not\ngit-fetch.sh.\n\n-- >8 --\ndiff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt\nindex fd44f62..660c18f 100644\n--- a/Documentation/git-repo-config.txt\n+++ b/Documentation/git-repo-config.txt\n@@ -23,10 +23,11 @@ You can query/set/replace/unset options \n actually the section and the key separated by a dot, and the value will be\n escaped.\n \n-If you want to set/unset an option which can occur on multiple lines, you\n-should provide a POSIX regex for the value. If you want to handle the lines\n-*not* matching the regex, just prepend a single exclamation mark in front\n-(see EXAMPLES).\n+If you want to set/unset an option which can occur on multiple\n+lines, a POSIX regexp `value_regex` needs to be given. Only the\n+existing values that match the regexp are updated or unset. If\n+you want to handle the lines that do *not* match the regex, just\n+prepend a single exclamation mark in front (see EXAMPLES).\n \n The type specifier can be either '--int' or '--bool', which will make\n 'git-repo-config' ensure that the variable(s) are of the given type and\n"},{"id":"19672","messageId":"Pine.LNX.4.64.0605071629080.3718@g5.osdl.org","threadId":"4098","inReplyTo":"1147037659.25090.25.camel@dv","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-08T00:05:26Z","receivedAt":"2006-05-08T00:05:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 7 May 2006, Pavel Roskin wrote:\n>\n> I think a good implementation should allow any characters in the keys,\n> even \"=\", because the key can be quoted. Section names may disallow\n> square brackets and dots.\n\nThat wouldn't help. The thing is designed to not only need no quoting \n(except for the _value_), it also is designed to have both section and key \nnames ignore case. So you really aren't supposed to put things like branch \nnames (which are potentially case-sensitive, depending on filesystem) in \neither.\n\nAnd we depend on that (and I think it's important - users normally should \n_not_ care about capitalization)\n\nSo you'd need to literally create a different syntax if you want unquoted \nsection naming.\n\n> Such limitations make it unpractical to use branch names in section or\n> key names. I'd like to have it fixed.\n\nHere's a possible syntax/patch. I actually think the quoting makes more \nsense in the section name, since you'll usually want several keys under \neach branch, so it makes sense to make the _branch_ be the section.\n\nIt basically makes it a special case if you have the section name be \nmarked with quotes, like\n\n\t[\"XyZZy\"]\n\nand in that case it turns the _real_ section name into the string \n\"branch.XyZZy\", where the important part is that it does this without \nchanging case or limiting the character set (but it will _not_ allow a \nnewline) in any way.\n\nSo you could have something like\n\n\t[\"Origin\"]\n\t\tURL = ...\n\t\tfetch = master\n\nand it would just turn it into\n\n\tbranch.Origin.url = ...\n\tbranch.Origin.fetch = master\n\netc.\n\nNo, I'm not sure this is the best possible syntax. It's just a suggestion. \nAnd it's certainly simple enough.\n\nThe downside is that if you start using config files like this, you \nliterally can't go back to older git versions. They'll refuse to touch \nsuch a config file (rather than just ignoring the new entries) and will \nexit with nasty messages. That might be unacceptable.\n\nInstead of quoting with double-quotes, it might be ok to use some \nalternate syntax line \"[:$branchname:]\" which looks visually reasonable, \nand has the potential advantage that ':' is already an invalid character \nin a branch name, so you don't actually even need any quoting logic at all \nat that point.\n\nI think the\n\n\t[\"branch\"]\n\t\t...\n\nsyntax looks reasonably readable and clean.\n\n\t\tLinus\n\n----\ndiff --git a/config.c b/config.c\nindex 41066e4..802e326 100644\n--- a/config.c\n+++ b/config.c\n@@ -134,9 +134,44 @@ static int get_value(config_fn_t fn, cha\n \treturn fn(name, value);\n }\n \n+static int get_branch_name(char *name)\n+{\n+\tint baselen = 7;\n+\tint quote = 0;\n+\n+\tmemcpy(name, \"branch.\", 7);\n+\tfor (;;) {\n+\t\tint c = get_next_char();\n+\t\tif (c == EOF)\n+\t\t\treturn -1;\n+\t\tif (c == '\\n')\n+\t\t\treturn -1;\n+\t\tif (!quote) {\n+\t\t\tif (c == '\"')\n+\t\t\t\tbreak;\n+\t\t\tif (c == ']')\n+\t\t\t\treturn -1;\n+\t\t\tif (c == '\\\\') {\n+\t\t\t\tquote = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t}\n+\t\tname[baselen++] = c;\n+\t\tif (baselen > MAXNAME / 2)\n+\t\t\treturn -1;\n+\t}\n+\tif (get_next_char() != ']')\n+\t\treturn -1;\n+\treturn baselen;\n+}\n+\n static int get_base_var(char *name)\n {\n \tint baselen = 0;\n+\tint c = get_next_char();\n+\n+\tif (c == '\"')\n+\t\treturn get_branch_name(name);\n \n \tfor (;;) {\n \t\tint c = get_next_char();\n"},{"id":"19673","messageId":"Pine.LNX.4.64.0605071713410.3718@g5.osdl.org","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605071629080.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-08T00:18:23Z","receivedAt":"2006-05-08T00:18:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 7 May 2006, Linus Torvalds wrote:\n>\n> And it's certainly simple enough.\n\nWell, simple enough to be buggy.\n\n> static int get_base_var(char *name)\n> {\n> \tint baselen = 0;\n> +\tint c = get_next_char();\n> +\n> +\tif (c == '\"')\n> +\t\treturn get_branch_name(name);\n> \n> \tfor (;;) {\n> \t\tint c = get_next_char();\n\nYou also need to move the \"int c = get_next_char()\" in the for() loop down \nto the end of the loop (removing the \"int\", of course).\n\nSo here's the fixed thing in case people care (and this time I actually \nlooked at whether it might even work, not just compile ;)\n\n\t\tLinus\n---\ndiff --git a/config.c b/config.c\nindex 41066e4..69d451a 100644\n--- a/config.c\n+++ b/config.c\n@@ -134,12 +134,46 @@ static int get_value(config_fn_t fn, cha\n \treturn fn(name, value);\n }\n \n+static int get_branch_name(char *name)\n+{\n+\tint baselen = 7;\n+\tint quote = 0;\n+\n+\tmemcpy(name, \"branch.\", 7);\n+\tfor (;;) {\n+\t\tint c = get_next_char();\n+\t\tif (c == EOF)\n+\t\t\treturn -1;\n+\t\tif (c == '\\n')\n+\t\t\treturn -1;\n+\t\tif (!quote) {\n+\t\t\tif (c == '\"')\n+\t\t\t\tbreak;\n+\t\t\tif (c == ']')\n+\t\t\t\treturn -1;\n+\t\t\tif (c == '\\\\') {\n+\t\t\t\tquote = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t}\n+\t\tname[baselen++] = c;\n+\t\tif (baselen > MAXNAME / 2)\n+\t\t\treturn -1;\n+\t}\n+\tif (get_next_char() != ']')\n+\t\treturn -1;\n+\treturn baselen;\n+}\n+\n static int get_base_var(char *name)\n {\n \tint baselen = 0;\n+\tint c = get_next_char();\n+\n+\tif (c == '\"')\n+\t\treturn get_branch_name(name);\n \n \tfor (;;) {\n-\t\tint c = get_next_char();\n \t\tif (c == EOF)\n \t\t\treturn -1;\n \t\tif (c == ']')\n@@ -149,6 +183,7 @@ static int get_base_var(char *name)\n \t\tif (baselen > MAXNAME / 2)\n \t\t\treturn -1;\n \t\tname[baselen++] = tolower(c);\n+\t\tc = get_next_char();\n \t}\n }\n \n"},{"id":"19674","messageId":"Pine.LNX.4.64.0605071718440.3718@g5.osdl.org","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605071629080.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-08T00:25:41Z","receivedAt":"2006-05-08T00:25:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 7 May 2006, Linus Torvalds wrote:\n>\n> The downside is that if you start using config files like this, you \n> literally can't go back to older git versions. They'll refuse to touch \n> such a config file (rather than just ignoring the new entries) and will \n> exit with nasty messages. That might be unacceptable.\n\nSide note: with this syntax, the _users_ will all just basically do\n\n\tif (!strncmp(name, \"branch.\", 7)) {\n\t\tbranch = name + 7;\n\t\tdot = strchr(branch, '.');\n\t\tif (!dot)\n\t\t\treturn -1;\n\t\t*dot++ = 0;\n\t\t.. we now have the branchname in \"branc\",\n\t\t and the rest in \"dot\" ..\n\nand if your branch names are purely alphabetical and lower-case, you can \nnow write\n\n\t[branch.origin]\n\t\tremote = true\n\t\turl = git://git.kernel.org/...\n\t\tfetch = master\n\n\t[branch.master]\n\t\tpull = origin\n\nand it will be parsed _exactly_ the same as\n\n\t[\"origin\"]\n\t\tremote = true\n\t\turl = git://git.kernel.org/...\n\t\tfetch = master\n\n\t[\"master\"]\n\t\tpull = origin\n\nwhile the [branch.origin] syntax allows old versions of git to happily \nignore it. So that would be a kind of cheesy work-around: the new \ndouble-quoted format is only _required_ for any branch-names that have \nspecial characters in it.\n\n\t\tLinus\n"},{"id":"19678","messageId":"BAYC1-PASMTP08D42DA222BA9843352CC1AEA80@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605071629080.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-08T00:34:58Z","receivedAt":"2006-05-08T00:34:58Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 7 May 2006 17:05:26 -0700 (PDT)\nLinus Torvalds wrote:\n\n> So you could have something like\n> \n> \t[\"Origin\"]\n> \t\tURL = ...\n> \t\tfetch = master\n> \n> and it would just turn it into\n> \n> \tbranch.Origin.url = ...\n> \tbranch.Origin.fetch = master\n> \n\nHaving magic sections that prepend \"branch.\" seems a bit suspect;\nwhy not just be explicit:\n\n [branch.Origin]\n URL = ...\n fetch = master\n\nWouldn't it be reasonable for git to impose modest restrictions on\nbranch names; such as restricting them to [a-zA-Z0-9] characters?\nThen we just have to make section names case sensitve within the\nconfig file; keys could still be case insensitive.\n\nActually it would be nice if we were consistent. If case matters to\ngit then the config file should be case sensitive. If case doesn't\nmatter to git, then it should consider \"Branch\", \"branch\" and \"BrAnCh\"\nas the same in all contexts (eg. git branch -b BrAnCh). It seems\nsilly for us to say people are too dumb to handle case sensitivity\nin a config file, but it's perfectly acceptable everywhere else.\n\nSean\n"},{"id":"19677","messageId":"1147048587.17371.13.camel@dv","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605071629080.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-08T00:36:27Z","receivedAt":"2006-05-08T00:36:27Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Linus!\n\nOn Sun, 2006-05-07 at 17:05 -0700, Linus Torvalds wrote:\n\n> The downside is that if you start using config files like this, you \n> literally can't go back to older git versions. They'll refuse to touch \n> such a config file (rather than just ignoring the new entries) and will \n> exit with nasty messages. That might be unacceptable.\n\nYou code faster that I write e-mails :-)\n\nI like your approach, even though it breaks compatibility. I understand\nwe are going to more .git/remotes to the config, so compatibility will\nbe broken anyways.\n\nI'm only concerned that we would be hardcoding the word \"branch\". We\ncould need fancy section names for other things in the future.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"19680","messageId":"Pine.LNX.4.63.0605080236350.32508@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"7v4q01jwwg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-08T00:43:50Z","receivedAt":"2006-05-08T00:43:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 7 May 2006, Junio C Hamano wrote:\n\n> Pavel Roskin writes:\n> \n> > In particular, git-repo-config leaves the config file locked in the\n> > regex is wrong:\n> >\n> > $ git-repo-config branch.fetch \"master:origin\" +\n> > Invalid pattern: +\n> > $ git-repo-config branch.fetch \"master:origin\" +\n> > could not lock config file\n> >\n> > To fix it, just add \"close(fd); unlink(lock_file);\" after \"Invalid\n> > pattern\" in config.c.\n> \n> I'd give Johannes the first refusal right to deal with this and\n> not touch repo-config.c myself for now, since I suspect I\n> tempted him enough to restructure it ;-).\n\nThanks. Yes, you tempted me real hard :-) Unfortunately, the restructuring \nwill have to wait a little, because I really should work for my day job \nthese days... :-(\n\n> > I don't quite understand what pattern is needed to add an entry. \"foo\"\n> > seems to work fine, I don't know why.\n> \n> I think the value regexp is \"replace the ones that match this\",\n> and the convention he came up with is to use \"^$\" to append (see\n> some examples in t/t1300-repo-config.sh).\n> \n> In any case, Documentation/git-repo-config.txt mentions\n> value_regex without explaining what the semantics is. This\n> needs to be fixed, probably like the attached patch.\n> \n> > That problem with multiple values is that they are quite fragile and\n> > require special options to access them. Since regex is used, dots in\n> > the branch names need to be escaped. Probably more escapes are needed.\n> \n> I have a suspicion that using regex while is more powerful and\n> expressive might be a mistake and it would be easier for users\n> (both Porcelain and end-users) to use fnmatch() patterns.\n\nI did not know about fnmatch()... It is probably better than regular \nexpressions. After all, what I use it for most often is\n\n\tgit-repo-config --get-all remote.*url\n\nwhich -- magically -- will continue to work with fnmatch()!\n\n> \t[branch]\n> \t\tdefaultremote = origin for master\n> defaultremote = private for test\n\nFWIW I like that syntax much better. But then, somebody called me weird \nbecause of how I order the arguments of a comparison... tsk, tsk.\n\n> @@ -23,10 +23,11 @@ You can query/set/replace/unset options \n> actually the section and the key separated by a dot, and the value will be\n> escaped.\n> \n> -If you want to set/unset an option which can occur on multiple lines, you\n> -should provide a POSIX regex for the value. If you want to handle the lines\n> -*not* matching the regex, just prepend a single exclamation mark in front\n> -(see EXAMPLES).\n> +If you want to set/unset an option which can occur on multiple\n> +lines, a POSIX regexp `value_regex` needs to be given. Only the\n> +existing values that match the regexp are updated or unset. If\n> +you want to handle the lines that do *not* match the regex, just\n> +prepend a single exclamation mark in front (see EXAMPLES).\n\nI would actually prefer to go with your suggestion of using shell patterns \ninstead of regular expressions. They are not needed, and most users tend \nto positively hate regular expressions.\n\nThoughts?\n\nCiao,\nDscho\n"},{"id":"19679","messageId":"Pine.LNX.4.64.0605071740550.3718@g5.osdl.org","threadId":"4098","inReplyTo":"1147048587.17371.13.camel@dv","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-08T00:43:51Z","receivedAt":"2006-05-08T00:43:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 7 May 2006, Pavel Roskin wrote:\n> \n> I'm only concerned that we would be hardcoding the word \"branch\". We\n> could need fancy section names for other things in the future.\n\nFair enough. We could have used some fake section name that you can't \ngenerate any other way (in fact, \"Branch.$branchname\" would be that), but \nthe upside of using \"branch\" is exactly that you _can_ generate it with \nthe old-style syntax that is acceptable to older git versions too.\n\nSo the common case (all-lowercase, no special characters branch names) \nwouldn't need to break.\n\nNow, backwards competibility for the .git/config file isn't likely a huge \nissue, but it does matter if you want to do things like \"git bisect\" to \nbisect a totally unrelated bug, and part of the bisection is actually to \ninstall the older git version that you're testing for the bug..\n\n(Which is probably an insane thing to do anyway - you should be able to \ntest any bugs _without_ actually having to install the git version you're \ntesting. But whatever..)\n\n\t\tLinus\n"},{"id":"19682","messageId":"Pine.LNX.4.64.0605071751050.3718@g5.osdl.org","threadId":"4098","inReplyTo":"BAYC1-PASMTP08D42DA222BA9843352CC1AEA80@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-08T00:55:25Z","receivedAt":"2006-05-08T00:55:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 7 May 2006, sean wrote:\n> \n> Having magic sections that prepend \"branch.\" seems a bit suspect;\n> why not just be explicit:\n> \n> [branch.Origin]\n> URL = ...\n> fetch = master\n\nExactly because section (and key) names are normally not case sensitive.\n\nEven the documentation actually talks about \"core.fileMode\" and \"[imap] \nFolders\". \n\n\t\tLinus\n"},{"id":"19684","messageId":"1147050279.17371.20.camel@dv","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605071751050.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-08T01:04:39Z","receivedAt":"2006-05-08T01:04:39Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Sun, 2006-05-07 at 17:55 -0700, Linus Torvalds wrote:\n> \n> On Sun, 7 May 2006, sean wrote:\n> > \n> > Having magic sections that prepend \"branch.\" seems a bit suspect;\n> > why not just be explicit:\n> > \n> > [branch.Origin]\n> > URL = ...\n> > fetch = master\n> \n> Exactly because section (and key) names are normally not case sensitive.\n> \n> Even the documentation actually talks about \"core.fileMode\" and \"[imap] \n> Folders\". \n\nMake it [\"branch.Origin\"]\n\nNo hardcoded \"branch\" prepending needed. The case sensitive name is\nstill protected by quotes. This extends trivially to [\"user.Linus\"] or\n[\"path./src/git.c\"] or whatever.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"19685","messageId":"Pine.LNX.4.63.0605080303410.13588@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605071718440.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-08T01:05:47Z","receivedAt":"2006-05-08T01:05:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 7 May 2006, Linus Torvalds wrote:\n\n> [...]\n> \n> and if your branch names are purely alphabetical and lower-case, you can \n> now write\n> \n> \t[branch.origin]\n> \t\tremote = true\n> \t\turl = git://git.kernel.org/...\n> \t\tfetch = master\n> \n> \t[branch.master]\n> \t\tpull = origin\n> \n> and it will be parsed _exactly_ the same as\n> \n> \t[\"origin\"]\n> \t\tremote = true\n> \t\turl = git://git.kernel.org/...\n> \t\tfetch = master\n> \n> \t[\"master\"]\n> \t\tpull = origin\n> \n> while the [branch.origin] syntax allows old versions of git to happily \n> ignore it. So that would be a kind of cheesy work-around: the new \n> double-quoted format is only _required_ for any branch-names that have \n> special characters in it.\n\nEek.\n\nThe [\"blablabla\"] syntax fails the is-it-obvious-what-this-does test. What \n*is* wrong with the \" for \" syntax? IIRC it was even proposed by you, and \nit happens to be backward compatible.\n\nCiao,\nDscho\n"},{"id":"19686","messageId":"BAYC1-PASMTP087BACE5DC41C608DDC18DAEA80@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605071751050.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-08T01:11:45Z","receivedAt":"2006-05-08T01:11:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 7 May 2006 17:55:25 -0700 (PDT)\nLinus Torvalds wrote:\n\n> On Sun, 7 May 2006, sean wrote:\n> > \n> > Having magic sections that prepend \"branch.\" seems a bit suspect;\n> > why not just be explicit:\n> > \n> > [branch.Origin]\n> > URL = ...\n> > fetch = master\n> \n> Exactly because section (and key) names are normally not case sensitive.\n\nRestore case sensitivity to config file parsing and the problem largely goes\naway. Or go the other route and remove case sensitivity from all the other \nbits (branches names etc..).\n\nSean\n"},{"id":"19687","messageId":"1147051300.17371.32.camel@dv","threadId":"4098","inReplyTo":"Pine.LNX.4.63.0605080303410.13588@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Implementing branch attributes in git config","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-08T01:21:40Z","receivedAt":"2006-05-08T01:21:40Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Johannes!\n\nOn Mon, 2006-05-08 at 03:05 +0200, Johannes Schindelin wrote:\n> The [\"blablabla\"] syntax fails the is-it-obvious-what-this-does test. What \n> *is* wrong with the \" for \" syntax? IIRC it was even proposed by you, and \n> it happens to be backward compatible.\n\nNot trying to answer for Linus, here's my take.\n\nThe \"for\" syntax is one more layer in the config hierarchy. Adding\nanother layer is a more intrusive solution than relaxing the syntax of\nthe existing elements without changing their semantic.\n\ngit-repo-config is \"for\" agnostic. It doesn't parse \"for\" (as far as I\nknow).\n\n\"for\" can be confusing in some contexts, or may force inversion of the\nhierarchy to make the config file more readable. How would you\nimplement branch descriptions? See this:\n\n[branchdata]\ndescription = \"netdev\" for \"Network device development\"\n\nand this\n\n[branchdata]\ndescription = \"Network device development\" for \"netdev\"\n\nThe later is closer to English. Or should we use the first approach and\n\"is\" instead of \"for\"?\n\nNow, how can I get a description for the \"netdev\" branch by one\ngit-repo-config command, without pipes?\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"19689","messageId":"7vfyjli9vf.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605071740550.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-08T01:27:32Z","receivedAt":"2006-05-08T01:27:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 7 May 2006, Pavel Roskin wrote:\n>> \n>> I'm only concerned that we would be hardcoding the word \"branch\". We\n>> could need fancy section names for other things in the future.\n>\n> Fair enough. We could have used some fake section name that you can't \n> generate any other way (in fact, \"Branch.$branchname\" would be that), but \n> the upside of using \"branch\" is exactly that you _can_ generate it with \n> the old-style syntax that is acceptable to older git versions too.\n\nSorry, I do not follow the old-style syntax part.\n\nHow about keeping the default syntax as it is (tokens are case\ninsensitive and alnums only, dot separates tokens into\nsections), and when a token that violates that rule needs to be\nspelled out, require quoting, so:\n\n\tbranch.foo\tBranCh.FoO\tbranch.FOO\n\nare the same (section \"branch.foo\"), and if I have js/fmt.patch\nbranch, I need to spell the configuration for that branch like\nso:\n\n\tbranch.\"js/fmt.patch\"\tor \"branch.js/fmt.patch\" \n\nand the URL variable for that section is\n\n\t$ git repo-config '\"branch.js/fmt.patch\".url'\n\n(BTW, you could even have a variable with dots in it by quoting\nthe variable name, like \"branch.js/fmt.patch\".\"fetch.option\"; I\ndo not know if it is worth it).\n\nMy repository is full of topic branches that are named xx/yyyy.\nIt is very handy to be able to say \"show-branch --topics master\n'heads/??/*' next\" which would not show my other branches like\n\"test\", \"throwaway\", \"rework\", \"temp\", etc.\n"},{"id":"19690","messageId":"Pine.LNX.4.63.0605080327490.13794@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"1147051300.17371.32.camel@dv","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-08T01:27:57Z","receivedAt":"2006-05-08T01:27:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 7 May 2006, Pavel Roskin wrote:\n\n> On Mon, 2006-05-08 at 03:05 +0200, Johannes Schindelin wrote:\n> > The [\"blablabla\"] syntax fails the is-it-obvious-what-this-does test. What \n> > *is* wrong with the \" for \" syntax? IIRC it was even proposed by you, and \n> > it happens to be backward compatible.\n> \n> [branchdata]\n> description = \"netdev\" for \"Network device development\"\n> \n> and this\n> \n> [branchdata]\n> description = \"Network device development\" for \"netdev\"\n\nThe latter was how I recall the syntax proposed for proxies.\n\n> Now, how can I get a description for the \"netdev\" branch by one\n> git-repo-config command, without pipes?\n\n\tgit-repo-config --get branchdata.description ' for netdev$'\n\nHth,\nDscho\n"},{"id":"19691","messageId":"BAYC1-PASMTP0334B471C6908E4E40BFD2AEA80@CEZ.ICE","threadId":"4098","inReplyTo":"7vfyjli9vf.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-08T01:34:45Z","receivedAt":"2006-05-08T01:34:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 07 May 2006 18:27:32 -0700\nJunio C Hamano wrote:\n\n\n> How about keeping the default syntax as it is (tokens are case\n> insensitive and alnums only, dot separates tokens into\n> sections), and when a token that violates that rule needs to be\n> spelled out, require quoting, so:\n> \n> \tbranch.foo\tBranCh.FoO\tbranch.FOO\n \n> are the same (section \"branch.foo\"),\n\nDoesn't that mean you have to then prohibit creating mixed\ncase branches with \"git branch\" and \"git checkout -b\" ?\n\n> and if I have js/fmt.patch\n> branch, I need to spell the configuration for that branch like\n> so:\n> \n> \tbranch.\"js/fmt.patch\"\tor \"branch.js/fmt.patch\" \n> \n> and the URL variable for that section is\n> \n> \t$ git repo-config '\"branch.js/fmt.patch\".url'\n\nHow about transforming slashes into dots? so the above would \nbe:\n\n [branch.js.fmt.patch]\n\n And could be accessed by either:\n\n $ git repo-config branch.js.fmt.patch\n $ git repo-config branch.js/fmt.patch\n\n> (BTW, you could even have a variable with dots in it by quoting\n> the variable name, like \"branch.js/fmt.patch\".\"fetch.option\"; I\n> do not know if it is worth it).\n\nNot worth it. Branch names should be alnums and imho should be\ncase sensitive too.\n \n> My repository is full of topic branches that are named xx/yyyy.\n> It is very handy to be able to say \"show-branch --topics master\n> 'heads/??/*' next\" which would not show my other branches like\n> \"test\", \"throwaway\", \"rework\", \"temp\", etc.\n\nVery nice.\n\nSean\n"},{"id":"19693","messageId":"BAYC1-PASMTP076C2693FBB563A41CD193AEA80@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.63.0605080344480.14008@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-08T01:44:29Z","receivedAt":"2006-05-08T01:44:29Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 8 May 2006 03:45:47 +0200 (CEST)\nJohannes Schindelin wrote:\n\n> Hi,\n> \n> On Sun, 7 May 2006, sean wrote:\n> \n> > Not worth it. Branch names should be alnums and imho should be\n> > case sensitive too.\n> \n> Why should they be case sensitive? So you have a branch \"origin\" and \n> another named \"Origin\" and get totally confused?\n> \n\nI don't care either way, just think we should be consistent. Currently\nwe support case sensitivity in branch names and let people get \ntotally confused. But in practice people don't really get confused\nby the linux filesystem which is case sensitive.\n\nSean\n"},{"id":"19692","messageId":"Pine.LNX.4.63.0605080344480.14008@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"BAYC1-PASMTP0334B471C6908E4E40BFD2AEA80@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-08T01:45:47Z","receivedAt":"2006-05-08T01:45:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 7 May 2006, sean wrote:\n\n> Not worth it. Branch names should be alnums and imho should be\n> case sensitive too.\n\nWhy should they be case sensitive? So you have a branch \"origin\" and \nanother named \"Origin\" and get totally confused?\n\nCiao,\nDscho\n"},{"id":"19694","messageId":"1147053329.17371.52.camel@dv","threadId":"4098","inReplyTo":"Pine.LNX.4.63.0605080327490.13794@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Implementing branch attributes in git config","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-08T01:55:29Z","receivedAt":"2006-05-08T01:55:29Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2006-05-08 at 03:27 +0200, Johannes Schindelin wrote:\n> > Now, how can I get a description for the \"netdev\" branch by one\n> > git-repo-config command, without pipes?\n> \n> \tgit-repo-config --get branchdata.description ' for netdev$'\n\nNo, it doesn't remove \"for netdev\". What I really don't like is that\ngit-repo-config treats it as \"not my problem\".\n\ngit-repo-config places extremely tight limitations of the names of the\nsections and the keys. But sometimes a relationship between two loosely\ndefined strings needs to be presented. It's a real need. And\ngit-repo-config doesn't address this need.\n\nI believe git-repo-config should allow direct retrieval of data from any\ndepth, and the syntax should be explicit rather than fuzzy. A dot is\nmore explicit than \"for\", especially if the dot appears after a name\nthat may not contain dots.\n\nAnother question is how we want to group the data. Do we want to have\nall descriptions together or in separate sections? Whatever the answer,\ngit-repo-config should provide means to extract all data in one command,\nwithout need for postprocessing.\n\nSo I understand arguing where to place the branch name. But what I\ndon't like is the desire to offload part of the processing on the\ncallers.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"19697","messageId":"7vbqu9i6zl.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"BAYC1-PASMTP0334B471C6908E4E40BFD2AEA80@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-08T02:29:50Z","receivedAt":"2006-05-08T02:29:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"sean writes:\n\n> On Sun, 07 May 2006 18:27:32 -0700\n> Junio C Hamano wrote:\n>\n>\n>> How about keeping the default syntax as it is (tokens are case\n>> insensitive and alnums only, dot separates tokens into\n>> sections), and when a token that violates that rule needs to be\n>> spelled out, require quoting, so:\n>> \n>> \tbranch.foo\tBranCh.FoO\tbranch.FOO\n> \n>> are the same (section \"branch.foo\"),\n>\n> Doesn't that mean you have to then prohibit creating mixed\n> case branches with \"git branch\" and \"git checkout -b\" ?\n\nNot at all. Whatever Porcelain that runs repo-config to record\nthe branch name needs to spell that branch name with proper\nquoting, like:\n\n>> \tbranch.\"js/fmt.patch\"\tor \"branch.js/fmt.patch\" \n>> \n>> and the URL variable for that section is\n>> \n>> \t$ git repo-config '\"branch.js/fmt.patch\".url'\n>\n> How about transforming slashes into dots? so the above would \n> be:\n>\n> [branch.js.fmt.patch]\n\nI _do_ want to keep my slashes intact and also dots; mangling\nthem is not very nice to me X-<.\n"},{"id":"19700","messageId":"BAYC1-PASMTP110777A694DAF1D7623895AEA80@CEZ.ICE","threadId":"4098","inReplyTo":"7vbqu9i6zl.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-08T02:39:18Z","receivedAt":"2006-05-08T02:39:18Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 07 May 2006 19:29:50 -0700\nJunio C Hamano wrote:\n\n\n> Not at all. Whatever Porcelain that runs repo-config to record\n> the branch name needs to spell that branch name with proper\n> quoting, like:\n\nOkay. It just seems nuts to require quoting because you happen\nto use an uppercase character. People are used to quoting \nspecial characters like * and $, not uppercase letters.\n\n> I _do_ want to keep my slashes intact and also dots; mangling\n> them is not very nice to me X-<.\n\nYou're right.\n\nWe should just relax the config file rules for legal characters,\nin identifiers, at least [a-zA-Z0-9_/-].\n\nSean.\n"},{"id":"19706","messageId":"7vody8howu.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"1147053329.17371.52.camel@dv","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-08T09:00:17Z","receivedAt":"2006-05-08T09:00:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> On Mon, 2006-05-08 at 03:27 +0200, Johannes Schindelin wrote:\n>> > Now, how can I get a description for the \"netdev\" branch by one\n>> > git-repo-config command, without pipes?\n>> \n>> \tgit-repo-config --get branchdata.description ' for netdev$'\n>\n> No, it doesn't remove \"for netdev\". What I really don't like is that\n> git-repo-config treats it as \"not my problem\".\n\nStating what you do not like about something is a good first\nstep to improve that something. It should not be too hard to\nextend the parser to grok:\n\n\trepo-config --get branchdata.description '\\(.*\\) for netdev$'\n\nand when the value_regex has a capture return what matches\ninstead of the entire value. I think that would do what you\nwant.\n"},{"id":"19710","messageId":"Pine.LNX.4.63.0605081416140.29236@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"7vody8howu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-08T12:17:19Z","receivedAt":"2006-05-08T12:17:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 8 May 2006, Junio C Hamano wrote:\n\n> \trepo-config --get branchdata.description '\\(.*\\) for netdev$'\n\nPOSIX regexps do not want the backslashes...\n\nSomething like this?\n\n---\n[PATCH] repo-config: allow one group in value regexp\n\nThe regular expression for the value can now contain one group. In case\nthere is one, the output will be just that group, not the whole value.\nNow you can say\n\n git-repo-config --get branch.defaultremote '(.*) for junio'\n\nand for a config like this:\n\n [branch]\n defaultRemote = sushi for junio\n\nthe output will be \"sushi\".\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n repo-config.c | 30 ++++++++++++++++++++----------\n 1 files changed, 20 insertions(+), 10 deletions(-)\n\ndiff --git a/repo-config.c b/repo-config.c\nindex 63eda1b..9ac4c51 100644\n--- a/repo-config.c\n+++ b/repo-config.c\n@@ -26,31 +26,41 @@ static int show_all_config(const char *k\n static int show_config(const char* key_, const char* value_)\n {\n \tchar value[256];\n-\tconst char *vptr = value;\n+\tconst char *vptr = value_;\n \tint dup_error = 0;\n \n \tif (value_ == NULL)\n-\t\tvalue_ = \"\";\n+\t\tvptr = value_ = \"\";\n \n \tif (!use_key_regexp && strcmp(key_, key))\n \t\treturn 0;\n \tif (use_key_regexp && regexec(key_regexp, key_, 0, NULL, 0))\n \t\treturn 0;\n-\tif (regexp != NULL &&\n-\t\t\t (do_not_match ^\n-\t\t\t regexec(regexp, value_, 0, NULL, 0)))\n-\t\treturn 0;\n+\tif (regexp != NULL) {\n+\t\tregmatch_t matches[2];\n+\t\tint len;\n+\n+\t\tif (do_not_match ^ regexec(regexp, value_, 2, matches, 0))\n+\t\t\treturn 0;\n+\t\tlen = matches[1].rm_eo - matches[1].rm_so;\n+\t\tif (!do_not_match && len > 0) {\n+\t\t\tif (len > 255)\n+\t\t\t\tlen = 255;\n+\t\t\tstrncpy(value, value_ + matches[1].rm_so, len);\n+\t\t\tvalue[len] = 0;\n+\t\t\tvptr = value;\n+\t\t}\n+\t}\n \n \tif (show_keys)\n \t\tprintf(\"%s \", key_);\n \tif (seen && !do_all)\n \t\tdup_error = 1;\n-\tif (type == T_INT)\n+\tif (type == T_INT) {\n \t\tsprintf(value, \"%d\", git_config_int(key_, value_));\n-\telse if (type == T_BOOL)\n+\t\tvptr = value;\n+\t} else if (type == T_BOOL)\n \t\tvptr = git_config_bool(key_, value_) ? \"true\" : \"false\";\n-\telse\n-\t\tvptr = value_;\n \tseen++;\n \tif (dup_error) {\n \t\terror(\"More than one value for the key %s: %s\",\n-- \n1.3.1.g297e8-dirty\n"},{"id":"19714","messageId":"1147101345.27362.15.camel@dv","threadId":"4098","inReplyTo":"7vody8howu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-08T15:15:45Z","receivedAt":"2006-05-08T15:15:45Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2006-05-08 at 02:00 -0700, Junio C Hamano wrote:\n> Stating what you do not like about something is a good first\n> step to improve that something. It should not be too hard to\n> extend the parser to grok:\n> \n> \trepo-config --get branchdata.description '\\(.*\\) for netdev$'\n> \n> and when the value_regex has a capture return what matches\n> instead of the entire value. I think that would do what you\n> want.\n\nOK, that would be acceptable.\n\nI still don't like the \"for\" conversion because it masquerades syntax\n(note that text to right of \"for\" must be unique) as plain text, but\nit's a matter of taste, so it's hard for me to argue about it.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"19726","messageId":"Pine.LNX.4.64.0605081905240.6713@iabervon.org","threadId":"4098","inReplyTo":"BAYC1-PASMTP110777A694DAF1D7623895AEA80@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-05-08T23:20:17Z","receivedAt":"2006-05-08T23:20:17Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 7 May 2006, sean wrote:\n\n> On Sun, 07 May 2006 19:29:50 -0700\n> Junio C Hamano wrote:\n> \n> \n> > Not at all. Whatever Porcelain that runs repo-config to record\n> > the branch name needs to spell that branch name with proper\n> > quoting, like:\n> \n> Okay. It just seems nuts to require quoting because you happen\n> to use an uppercase character. People are used to quoting \n> special characters like * and $, not uppercase letters.\n\nYou could tell people always to use:\n\n [branch.\"name\"]\n\neven if the branch name is all lowercase anyway. They could even use:\n\n [Branch.\"MyMixedCaseBranch\"]\n\nThen when you refer to something case-sensitive with the possibility of \nfunny characters, you put it in quotes, regardless of what it is.\n\nFor that matter, we could retain the quotes when we parse the file, and \nreject [branch.master] for lacking the quotes, so that people who are only \nexposed to branch names all in lowercase letters don't get habits that \nwill fail when they have a v2.6.16.x branch.\n\nI don't think that people are likely to use older versions of git on the \nsame repository they've used newer versions on. (Clones of it, sure, but \nthat doesn't matter here.) But we should, in any case, make the code \nignore sections or lines with syntax errors, under the assumption that \nthey're a later extension and possibly legal but not anything the code \ncould be interested in getting from a parser that doesn't support them.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"19727","messageId":"BAYC1-PASMTP0453E2D70B10C6D116167EAEA80@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605081905240.6713@iabervon.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-08T23:30:05Z","receivedAt":"2006-05-08T23:30:05Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 8 May 2006 19:20:17 -0400 (EDT)\nDaniel Barkalow wrote:\n\n> You could tell people always to use:\n> \n> [branch.\"name\"]\n> \n> even if the branch name is all lowercase anyway. They could even use:\n> \n> [Branch.\"MyMixedCaseBranch\"]\n> \n> Then when you refer to something case-sensitive with the possibility of \n> funny characters, you put it in quotes, regardless of what it is.\n> \n> For that matter, we could retain the quotes when we parse the file, and \n> reject [branch.master] for lacking the quotes, so that people who are only \n> exposed to branch names all in lowercase letters don't get habits that \n> will fail when they have a v2.6.16.x branch.\n> \n> I don't think that people are likely to use older versions of git on the \n> same repository they've used newer versions on. (Clones of it, sure, but \n> that doesn't matter here.) But we should, in any case, make the code \n> ignore sections or lines with syntax errors, under the assumption that \n> they're a later extension and possibly legal but not anything the code \n> could be interested in getting from a parser that doesn't support them.\n\n\nUnfortunately that's not the only place where you have to use the \nexcessive quoting; you also have to do the same when using the git\nrepo-config command line. All because we're clinging to case\ninsensitivity and a very restrictive set of characters for \nidentifiers in the config file. And just why are we clinging?\n\nBelieve when Linus offered the code originally he said that it was\neasier to start out very restrictive and loosen up later than it was\nto start loose and become restrictive later. That makes a lot of\nsense, but somewhere along the way we seem to have made a virtue\nout of something that is actually getting in the way of natural\nsyntactic usage. There's no good reason for git to break with \ntraditional and common practice in this case.\n\nSean\n"},{"id":"19728","messageId":"Pine.LNX.4.63.0605090137160.5755@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605081905240.6713@iabervon.org","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-08T23:40:52Z","receivedAt":"2006-05-08T23:40:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 8 May 2006, Daniel Barkalow wrote:\n\n> You could tell people always to use:\n> \n> [branch.\"name\"]\n\nI find this utterly ugly.\n\n> I don't think that people are likely to use older versions of git on the \n> same repository they've used newer versions on. (Clones of it, sure, but \n> that doesn't matter here.) But we should, in any case, make the code \n> ignore sections or lines with syntax errors, under the assumption that \n> they're a later extension and possibly legal but not anything the code \n> could be interested in getting from a parser that doesn't support them.\n\nI have to bisect git sometimes, just because I have some local changes. \nOlder gits do barf with a fatal error when encountering a bad config.\n\nFurther, it is probably not a good idea to relax error-checking. It is too \neasy to overlook.\n\nCiao,\nDscho\n"},{"id":"19729","messageId":"Pine.LNX.4.63.0605090142280.5778@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"BAYC1-PASMTP0453E2D70B10C6D116167EAEA80@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-08T23:44:31Z","receivedAt":"2006-05-08T23:44:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 8 May 2006, sean wrote:\n\n> There's no good reason for git to break with traditional and common \n> practice in this case.\n\nIt is well established common practice that ini files (and everything in \nconfig resembles an ini file) have case insensitive section headers as \nwell as keys.\n\nCiao,\nDscho\n"},{"id":"19731","messageId":"BAYC1-PASMTP03ADC2F3E75E482ADC5CD3AEA90@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.63.0605090142280.5778@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-09T00:08:26Z","receivedAt":"2006-05-09T00:08:26Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 9 May 2006 01:44:31 +0200 (CEST)\nJohannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 8 May 2006, sean wrote:\n> \n> > There's no good reason for git to break with traditional and common \n> > practice in this case.\n> \n> It is well established common practice that ini files (and everything in \n> config resembles an ini file) have case insensitive section headers as \n> well as keys.\n\nNot in ini files that support section headers that represent filenames\nand directories. Exactly because those things _are_ case sensitive \nand include more characters than just alnums. But we're not just \ntalking about the config file syntax we're talking about how the \nuser must ultimately refer to branches with uppercase character. \nNow everytime a person wants to add a branch attribute via repo-config\nthey have to remember that git thinks uppercase characters should\nbe quoted. Doesn't that sound ridiculous to you?\n\nThe point is that we should make the config file and the repo-config\ncommand easy for the _users_. Instead we're going to make them use\nsome crazy extra syntax because we refuse to come to terms with the\nlimitations of the choices we've made so far.\n\nOne option, which I don't really like and comes with its own set of \nproblems, would be to do something like:\n\n[branch1]\n streetname = \"p4/BrAnCH\"\n[branch2]\n streetname = \"origin\"\n\nAnd then allow reference to it from git-repo-config by either branch#\nor the value of street name. While it would take some extra coding\nbut at least it lives within the current restrictions for key names.\n\nIt just seems that once you have to even consider options like this,\na big red flag should be raised about some of the assumptions we've\nbuilt into the system.\n\nSean\n"},{"id":"19733","messageId":"Pine.LNX.4.63.0605090219250.6000@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"BAYC1-PASMTP03ADC2F3E75E482ADC5CD3AEA90@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-09T00:23:22Z","receivedAt":"2006-05-09T00:23:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 8 May 2006, sean wrote:\n\n> [branch1]\n> streetname = \"p4/BrAnCH\"\n> [branch2]\n> streetname = \"origin\"\n\nConceptually, it feels just wrong to me that a section name should contain \na filename. A section is something which contains data regarding a certain \nconcept. Such as \"core\", which has values concerning the core of git.\n\nIn that sense, I stay with my preferance:\n\n[branch]\n\tdefaultRemote = bla for bloop\n\tdefaultRemote = connery for sean\n\nNo need to extend the simple config file. And remember, it is so simple, \nbecause it is so strict.\n\nCiao,\nDscho\n"},{"id":"19736","messageId":"Pine.LNX.4.64.0605081731440.3718@g5.osdl.org","threadId":"4098","inReplyTo":"BAYC1-PASMTP03ADC2F3E75E482ADC5CD3AEA90@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-09T00:37:29Z","receivedAt":"2006-05-09T00:37:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 8 May 2006, sean wrote:\n> \n> One option, which I don't really like and comes with its own set of \n> problems, would be to do something like:\n> \n> [branch1]\n> streetname = \"p4/BrAnCH\"\n> [branch2]\n> streetname = \"origin\"\n\nYou don't actually need that.\n\nWe could easily do\n\n\t[branch]\n\t\tname = \"p4/BrAnCH\"\n\t\turl = git://git.kernel.org/...\n\t\tpull = master\n\n\t;\n\t; Repeating the \"[branch]\" section here isn't\n\t; needed, but doesn't hurt either, and is\n\t; more readable\n\t;\n\t[branch]\n\t\tname = \"origin\"\n\t\turl = ...\n\t\tpull = ...\n\nbecause the config file is always parsed linearly, and just \ntrigger on \"branch.name\", and keep that around when parsing \nanything else.\n\nThe problem with _that_ is that \"git repo-config\" can't add this kind of \nsetup sanely: it doesn't understand that kind of statefulness.\n\nThe above would work without any changes what-so-ever to the config format \nand readers - and old versions of git wouldn't react badly either. But the \nwriter would need to be taught about state.\n\n\t\tLinus\n"},{"id":"19740","messageId":"BAYC1-PASMTP02A6C811EC4FA46BBD95DDAEA90@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605081731440.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-09T00:49:33Z","receivedAt":"2006-05-09T00:49:33Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 8 May 2006 17:37:29 -0700 (PDT)\nLinus Torvalds wrote:\n\n> We could easily do\n> \n> \t[branch]\n> \t\tname = \"p4/BrAnCH\"\n> \t\turl = git://git.kernel.org/...\n> \t\tpull = master\n> \n> \t;\n> \t; Repeating the \"[branch]\" section here isn't\n> \t; needed, but doesn't hurt either, and is\n> \t; more readable\n> \t;\n> \t[branch]\n> \t\tname = \"origin\"\n> \t\turl = ...\n> \t\tpull = ...\n> \n> because the config file is always parsed linearly, and just \n> trigger on \"branch.name\", and keep that around when parsing \n> anything else.\n\nThat was pretty much what I was suggesting although i overlooked \nthe fact that you don't actually need to number the sections.\n\n> The problem with _that_ is that \"git repo-config\" can't add this kind of \n> setup sanely: it doesn't understand that kind of statefulness.\n\nShouldn't be too hard to deal with. So we would allow the following\ncommand to make the url entry above:\n\n $ git repo-config branch.p4/BrAnCH.url git://git.kernel.org/...\n\n> The above would work without any changes what-so-ever to the config format \n> and readers - and old versions of git wouldn't react badly either. But the \n> writer would need to be taught about state.\n\nWell it seems like maybe the best compromise, and it avoids having to put\nfiles and directories into section names which Johannes was objecting to.\n\nSean\n"},{"id":"19739","messageId":"7virogc90u.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605081731440.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-09T00:54:41Z","receivedAt":"2006-05-09T00:54:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 8 May 2006, sean wrote:\n>> \n>> One option, which I don't really like and comes with its own set of \n>> problems, would be to do something like:\n>> \n>> [branch1]\n>> streetname = \"p4/BrAnCH\"\n>> [branch2]\n>> streetname = \"origin\"\n>\n> You don't actually need that.\n>\n> We could easily do\n>\n> \t[branch]\n> \t\tname = \"p4/BrAnCH\"\n> \t\turl = git://git.kernel.org/...\n> \t\tpull = master\n>\n> \t;\n> \t; Repeating the \"[branch]\" section here isn't\n> \t; needed, but doesn't hurt either, and is\n> \t; more readable\n> \t;\n> \t[branch]\n> \t\tname = \"origin\"\n> \t\turl = ...\n> \t\tpull = ...\n>\n> because the config file is always parsed linearly, and just \n> trigger on \"branch.name\", and keep that around when parsing \n> anything else.\n>\n> The problem with _that_ is that \"git repo-config\" can't add this kind of \n> setup sanely: it doesn't understand that kind of statefulness.\n\nWait a minute... Statefulness is not the issue, I think.\n\nHow would you tell your updated repo-config what to update and\nwhat to look up?\n\n\t- I want the url for branch whose name is \"origin\"\n\n\t- I want to fetch their \"for-linus\" branch when fetching\n from the branch whose name is \"jgarzik\" from now on.\n\nIn these query and update, you _are_ naming the branch with\nname=\"xxx\"; you just made \"name\" a special attribute.\n\nNow, how would that compare with:\n\n [branch.jgarzik]\n url = git://git.kernel.org/...\n fetch = for-linus\n\nor\n\t[branch.\"JGarzik\"]\n url = git://git.kernel.org/...\n fetch = for-linus\n\nI would say if we are grouping things together, if we can give\nname to each group, _and_ if we are going to refer to the group\nwith its name, we are better off making the groups into distinct\nsections _and_ make the syntax obvious that what name refers to\nthe section. I think [branch.jgarzik] syntax is more obvious\nthan your example where \"name =\" line is implicitly used as a\nkeyword to differenciate multiple occurrences of [branch]\nsections.\n\nHaving said that, perhaps you have something more elaborate in mind,\ne.g.\n\n\trepo-config --get branch.url where name = 'origin'\n\trepo-config --get branch.name where url like 'git://%'\n\trepo-config branch.url 'git://git.kernel.org/...' where name = foo\n\n;-) ;-) ;-) ??? If that is what you are after, then I agree\nyour syntax is more generic and suitable. But otherwise I fail\nto see its point.\n\nOn a related topic, I have always been torn about the \"for\"\nconvention. While I think it was a cute hack, it would break\nquite badly once we start doing anything complex.\n\n\t[branch]\n \turl = git://git.kernel.org/... for jgarzik\n fetch = for-linus for jgarzik\n proxy = none\n\n \turl = git://git.kernel.org/... for torvalds\n fetch = master for torvalds\n"},{"id":"19746","messageId":"Pine.LNX.4.64.0605081801360.3718@g5.osdl.org","threadId":"4098","inReplyTo":"7virogc90u.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-09T01:05:13Z","receivedAt":"2006-05-09T01:05:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 8 May 2006, Junio C Hamano wrote:\n> >\n> > The problem with _that_ is that \"git repo-config\" can't add this kind of \n> > setup sanely: it doesn't understand that kind of statefulness.\n> \n> Wait a minute... Statefulness is not the issue, I think.\n\nWell, it does end up being..\n\n> How would you tell your updated repo-config what to update and\n> what to look up?\n> \n> \t- I want the url for branch whose name is \"origin\"\n> \n> \t- I want to fetch their \"for-linus\" branch when fetching\n> from the branch whose name is \"jgarzik\" from now on.\n\nExactly, git repo-config would have to know about this magic thing, and \nhave a special argument like\n\n\t--state=branch.name\n\nthat says that \"state\" is to be taken from the \"branch.name\" variable when \nseen.\n\nThen, in addition to the regexp, you would have a way to trigger on the \n\"state\" variable.\n\n> Now, how would that compare with:\n> \n> [branch.jgarzik]\n> url = git://git.kernel.org/...\n> fetch = for-linus\n> \n> or\n> \t[branch.\"JGarzik\"]\n> url = git://git.kernel.org/...\n> fetch = for-linus\n\nIt would be _able_ to do all the same things, but thanks to statefulness \nyou'd be able to keep the section (and key) names the way they are.\n\n> On a related topic, I have always been torn about the \"for\"\n> convention.\n\nI agree. And I think it's actually very much the same thing. It adds \nstate, but it adds it to each _value_, instead of adding it once \"before\" \nthe values.\n\n\t\tLinus\n"},{"id":"19751","messageId":"7v1wv4c7wk.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605081801360.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-09T01:18:51Z","receivedAt":"2006-05-09T01:18:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 8 May 2006, Junio C Hamano wrote:\n>> \n>> Wait a minute... Statefulness is not the issue, I think.\n>\n> Well, it does end up being..\n\nNot really, you ended up making it so, perhaps, but I do not\nthink it needs to be.\n\nYou dodged my comments on the SQL-like queries ;-). I was half\n(perhaps 3/4) joking, but some people actually might like to be\nable to say:\n\n\tgit repo-config --get-all branch.name where url like 'git://%'\n\nto list all the repositories reachable via git-native protocol.\n\nOops, by the way, why does a [branch] have url as its attribute?\nI think this was a bad example -- we are talking about [remote]\nhere. But the main point is about syntax, so that is OK.\n\n> Exactly, git repo-config would have to know about this magic thing, and \n> have a special argument like\n>\n> \t--state=branch.name\n>\n> that says that \"state\" is to be taken from the \"branch.name\" variable when \n> seen.\n>\n> Then, in addition to the regexp, you would have a way to trigger on the \n> \"state\" variable.\n\nI am reluctant to buy that argument (I see it is an easy way\nfrom the implementation point of view) -- it appears to me that\nit would invite this easy user error.\n\n\n\t[branch]\n \tname = linus\n \turl = git://git.kernel.org/../torvalds/linux-2.6\n\n\t[branch]\n \turl = git://git.kernel.org/../jgarzik/libata-dev\n \tname = libata\n\n> It would be _able_ to do all the same things, but thanks to statefulness \n> you'd be able to keep the section (and key) names the way they are.\n\nYes, but that statefulness is inviting user errors, and you need\nto update repo-config and config parser anyway, so I still do\nnot see what the advantage is.\n"},{"id":"19753","messageId":"Pine.LNX.4.64.0605081828250.3718@g5.osdl.org","threadId":"4098","inReplyTo":"7v1wv4c7wk.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-09T01:30:55Z","receivedAt":"2006-05-09T01:30:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 8 May 2006, Junio C Hamano wrote:\n> \n> You dodged my comments on the SQL-like queries ;-). I was half\n> (perhaps 3/4) joking, but some people actually might like to be\n> able to say:\n> \n> \tgit repo-config --get-all branch.name where url like 'git://%'\n\nI think databases tend to be a huge mistake. Show me a SQL database where \nusers can edit the data by hand, and it's all readable, and maybe I'll \nchange my mind.\n\nThe monotone guys have almost everything in a database, and from what I \ncan tell it results in (a) you can do some really funky queries and (b) \nit's confusing and slow as hell.\n\nNow, the speed issue doesn't matter for a config file, but there the \neditability very much does.\n\n> Oops, by the way, why does a [branch] have url as its attribute?\n> I think this was a bad example -- we are talking about [remote]\n> here. But the main point is about syntax, so that is OK.\n\nYeah, \"remote\" is clearly better than \"url\".\n\n> I am reluctant to buy that argument (I see it is an easy way\n> from the implementation point of view) -- it appears to me that\n> it would invite this easy user error.\n> \n> \t[branch]\n> \tname = linus\n> \turl = git://git.kernel.org/../torvalds/linux-2.6\n> \n> \t[branch]\n> \turl = git://git.kernel.org/../jgarzik/libata-dev\n> \tname = libata\n\nYes, that would be a silent and confusing error.\n\n\t\tLinus\n"},{"id":"19754","messageId":"Pine.LNX.4.64.0605081854190.3718@g5.osdl.org","threadId":"4098","inReplyTo":"7v1wv4c7wk.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-09T01:57:08Z","receivedAt":"2006-05-09T01:57:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 8 May 2006, Junio C Hamano wrote:\n> \n> Yes, but that statefulness is inviting user errors, and you need\n> to update repo-config and config parser anyway, so I still do\n> not see what the advantage is.\n\nBtw, I keep coming back to the same\n\n\t[\"jc/show-branch-dense\"]\n\t\tremote = git://...\n\nbranch specifier syntax. It just seems very intuitive and is easy to \nparse. \n\nThe only real downside ends up being the non-forwards-compatibility thing. \nBut trying to be forwards-compatible for old git versions with this thing \nwould seem to be a major pain for rather slim gain.\n\n\t\t\tLinus\n"},{"id":"19756","messageId":"BAYC1-PASMTP04C9C4BF5B89E55B9D877AAEA90@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605081854190.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-09T02:47:21Z","receivedAt":"2006-05-09T02:47:21Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 8 May 2006 18:57:08 -0700 (PDT)\nLinus Torvalds wrote:\n\n> Btw, I keep coming back to the same\n> \n> \t[\"jc/show-branch-dense\"]\n> \t\tremote = git://...\n> \n> branch specifier syntax. It just seems very intuitive and is easy to \n> parse. \n\nWe already need such section headers for remotes, and for branches.. \nboth which may well need to be quoted as above.. how to distinguish\nbetween them? How to handle the next case that comes along where we\nwant these special header semantics?\n\nWe really need:\n\n [branch.Whatever]\n\nand:\n\n [remote.Whatever]\n\nAs in the case of \"origin\" where we have a remote and a branch\nnamed that.\n\n\n> The only real downside ends up being the non-forwards-compatibility thing. \n> But trying to be forwards-compatible for old git versions with this thing \n> would seem to be a major pain for rather slim gain.\n\nWhat's the advantage of section quotation marks over just allowing these\ncharacters in regular section names? To be specific, what is wrong with:\n\n [jc/show-branch-dense]\n remote = git://...\n\nIf we just relax the legal characters in identifiers to include slash and dash?\nIt doesn't seem to be any different in amount of code needed to achieve, and it\nis just as intuitive (perhaps more so) and no worse on the forward-compatibility\nthing.\n\nIf we continue with case insensitive section names, it's quite possible for \nthe user to mess up while hand editing or forgetting proper \"git\" quoting\nrules on the command line and end up with silent breakage:\n\n$ git repo-config \"Branch\".url = git://... \n (updates section [\"Branch\"])\n\nAnd then the next time forget the quotes and use:\n\n$ git repo-config Branch.url = git://... \n (updates section [branch])\n\nAnd all of a sudden the user is updating _different_ sections with \nunpredictable results. This is just awkward; why not just admit that \nsection names should always be case sensitive if we're going to put\nfilenames inside them?\n\nSean\n"},{"id":"19759","messageId":"BAYC1-PASMTP05953E2B948CB07A171FD8AEA90@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605082007100.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-09T03:07:52Z","receivedAt":"2006-05-09T03:07:52Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 8 May 2006 20:08:41 -0700 (PDT)\nLinus Torvalds wrote:\n\n> On Mon, 8 May 2006, sean wrote:\n> > \n> > What's the advantage of section quotation marks over just allowing these\n> > characters in regular section names? To be specific, what is wrong with:\n> > \n> > [jc/show-branch-dense]\n> \n> This would _suck_\n> \n> What if you have a branch called \"core\"? Not all all unlikely. \n> \n> Think about what a section like\n> \n> \t[core]\n> \n> really means.\n\n\nYeah, but the part of my message you didn't quote made it quite clear i know\nabout this problem, what i would really propose is:\n\n[core]\n ...\n[branch.core]\n ...\n[remote.core]\n ...\n\netc...\n \n> Plus I really want to not be case sensitive by default. Case sensitivity \n> really is _not_ normal for this kind of config file syntax.\n\nBut it's not just the config file, it's also how it ends up being used\non the command line.. you have to admit silent differences between\nthese two command lines is _not_ desirable:\n\n $ git repo-config \"Branch\".url \n $ git repo-config Branch.url\n\nThat can't be something you want to see either.\n\nSean\n"},{"id":"19758","messageId":"Pine.LNX.4.64.0605082007100.3718@g5.osdl.org","threadId":"4098","inReplyTo":"BAYC1-PASMTP04C9C4BF5B89E55B9D877AAEA90@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-09T03:08:41Z","receivedAt":"2006-05-09T03:08:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 8 May 2006, sean wrote:\n> \n> What's the advantage of section quotation marks over just allowing these\n> characters in regular section names? To be specific, what is wrong with:\n> \n> [jc/show-branch-dense]\n\nThis would _suck_\n\nWhat if you have a branch called \"core\"? Not all all unlikely. \n\nThink about what a section like\n\n\t[core]\n\nreally means.\n\nPlus I really want to not be case sensitive by default. Case sensitivity \nreally is _not_ normal for this kind of config file syntax.\n\n\t\t\tLinus\n"},{"id":"19760","messageId":"Pine.LNX.4.64.0605082100460.3718@g5.osdl.org","threadId":"4098","inReplyTo":"BAYC1-PASMTP05953E2B948CB07A171FD8AEA90@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-09T04:11:24Z","receivedAt":"2006-05-09T04:11:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 8 May 2006, sean wrote:\n>\n> [core]\n> ...\n> [branch.core]\n> ...\n> [remote.core]\n> ...\n\nOk. In that case, I would suggest a much more readable format:\n\n\t[core]\n\t\t...\n\n\t[branch \"core\"]\n\t\t...\n\n\t[remote \"core\"]\n\t\t...\n\nand yes, enforce the + format. We'd turn it internally \ninto some random internal string format (probably replacing the space with \na dot, and removing the quotes, so it would become \"remote.core.\").\n\n> But it's not just the config file, it's also how it ends up being used\n> on the command line.. \n\nActually, the command line migth as well allow any strange thing, and \n_add_ the quotes internally. So you could do something that does\n\n\tgit repo-config set Remote.Core.Pull master\n\nand we could just let that generate\n\n\t[remote \"Core\"]\n\t\tpull = master\n\nor whatever.\n\nI care about the _file_ being human-editable, but that means that I think \nit's perfectly fine to have some smarts in the tools that help us do so, \nand let them recognize the magic \"remote\" and \"branch\" prefixes.\n\n\t\tLinus\n"},{"id":"19761","messageId":"1147148425.4453.43.camel@dv","threadId":"4098","inReplyTo":"20060508230752.43118643.seanlkml@sympatico.ca","subject":"Re: Implementing branch attributes in git config","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-09T04:20:25Z","receivedAt":"2006-05-09T04:20:25Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nI feel so bad that I sparked this discussion about config files and\ncouldn't participate in it in real time. I'd like to summarize my\nthoughts on the subject - maybe they will help us come to an agreement.\n\nUser convenience trumps backward compatibility.\n\nCase in-sensitivity is almost a foreign concept for POSIX. There is no\nexpectation (except among newbies) that bash would run grep if it's\nasked to run Grep. Why would git-repo-config need to foster such\nexpectations, and do so inconsistently, e.g. for key names but not for\nvalues?\n\nThe config files use escaping by backslash, which is easier to work with\nthan quoting. Quoting should be introduced if backslash escaping\ndoesn't work, and I think backslash escaping in fine.\n\nUsers who edit the config file manually and mindlessly get what they\ndeserve. Users who misspell \"master\" as \"Master\" get what they deserve.\nOccasional typos could be caught and reported if practical, but hand\nholding shouldn't be a design goal.\n\nEither we need the third layer in key hierarchy, and that layer should\nsupport user defined strings, or we need to relax one of the layers to\nuser define strings. User defined means that it can include spaces,\nslashes, dots and many other characters. Whenever a character is not\nallowed, we should have a good reason.\n\nAn example of two-layer approach:\n\n[branchdescriptions]\n\tmaster = My master branch\n\tnetdev-master = Patches for netdev\n[branchremotes]\n\tmaster = origin\n\tnetdev-master = netdev\n\nAll other examples quoted here are examples of three-layer approach.\nEither the extra key is inserted into the section name (Linus) or into\nthe value (Dscho). It can also be inserted into the existing key.\n\nIf we want to group all branch properties for each branch, we have to go\nthree-layer. If we don't want that, the above example should accepted\nas the simplest approach.\n\nAdding an additional key layer to the existing keys is syntactically\nnice, but buys us very little in terms of ability to group branch data:\n\n[branchdata]\n\tremote[master] = origin\n\tremote[netdev-master] = master\n\tdescription[master] = My master branch\n\tdescription[netdev-master] = Patches for netdev\n\nAdding an additional key layer to the value is inherently fragile. The\nvalue has free format, and so is the new key. It also has the same\nproblem that the data for different branches is mixed together.\n\nAdding an additional key layer to the section name looks strange\nsyntactically, but it's the approach that gives us immediate grouping of\nall branch data for every branch.\n\nMy personal preference is the Linus' proposal, but with backslash\nescaping instead of quoting, with explicit \"branch.\" in the section\nnames, and with case sensitive sections and keys.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"19762","messageId":"e3p5om$djs$1@sea.gmane.org","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605082100460.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-09T04:28:09Z","receivedAt":"2006-05-09T04:28:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> I would suggest a much more readable format:\n> \n> [core]\n> ...\n> \n> [branch \"core\"]\n> ...\n> \n> [remote \"core\"]\n> ...\n> \n> and yes, enforce the + format. We'd turn it internally\n> into some random internal string format (probably replacing the space with\n> a dot, and removing the quotes, so it would become \"remote.core.\").\n\nI'm all for it. Nice compromise of [branch.\"miXedCaps\"] and [\"miXedCaps\"],\nhuman readable end editable, and easy parsable.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19763","messageId":"7vslnj933a.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605081828250.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-09T05:31:05Z","receivedAt":"2006-05-09T05:31:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n>> \t[branch]\n>> \tname = linus\n>> \turl = git://git.kernel.org/../torvalds/linux-2.6\n>> \n>> \t[branch]\n>> \turl = git://git.kernel.org/../jgarzik/libata-dev\n>> \tname = libata\n>\n> Yes, that would be a silent and confusing error.\n\nAlthough I haved raised objections, I actually started to like\nthe idea of using multiple [branch] (or wasn't it [remote] given\nthe example variables we have been using?) sections.\n\nWe should first depart from the Windoze .INI mindset. While I\ndo not think users expect case insensisitivity, only because the\nsection headers are marked with [brackets], if that syntax\nsomehow makes people expect such, maybe we should stop using\n[bracket] as section markers.\n\nWhatever marker we end up using, I'd suggest somewhat different\napproach.\n\n - Treat each part that are grouped under [bracketted-string]\n marker as a bag of variable=value pairs. Loosely speaking,\n the bracketted-string defines a schema -- what kind of\n variables are expected to be there in that seciton. For\n example, a section for things we traditionally had in remotes\n file would contain fields (variables) such as url, fetch, and\n push (we might add proxy to this list). And we call this\n \"bag of variable=value\" a section.\n\n - There can be multiple sections in a config file that uses the\n same schema. The example at the beginning of this message\n is perfectly valid. It defines two sections of type\n [branch], each of which has two variables (name and url) in\n it.\n\nUnlike your earlier suggestion, the second [branch] is not just\nfor readability; it is mandatory, because we are talking about\ntwo different [branch]es (eh, that's [remote]s, really), it\nneeds to be there to separate two instances.\n\nThe above would break the existing repo-config command, but\nlet's forget about it for now. I think we are breaking\nforward/backward compatibility in any proposals brought up so\nfar anyway.\n\nWe would need user interface level commands to\n\n\tadd a new section\n delete a section\n\nWe would need a way to identify a secion, perhaps using a value\nof arbitrary key (e.g. \"where name=blah\"). Creating a section\ncould be implicit, just like the current repo-config.\n\n add a variable=value to a section\n delete a variable=value from a section\n\tretrieve variables' values from a section\n\tlist value of a variable from all sections of a kind.\n\nProbably need to support the same variable name appearing more\nthan once, just like the current multi-value support.\n\nThe current multi-value stuff assumes that multi-values are\nexceptions, and rare. While I do not necessarily agree with\nthat, for now let's assume that is true.\n\nCreating a new section with given variables:\n\n\t$ cfg --set section var value var value ...\n (eg) $ cfg --set branch name master merge origin pull linus\n\n Here, 'var' and 'value' are case sensitive; if they have\n syntactical metacharacters (WS, =, quotes, etc), they need\n to be quoted when cfg command writes to the file (i.e. the\n user do not have to quote more than necessary to protect\n them from the shell).\n\nUpdating an existing section's variables, or create a new one:\n\n\t$ cfg --replace section.var value where var0 = val0\n (eg) $ cfg --replace remote.url git://... where name = linus\n\n Look for a \"remote\" section that has a variable \"name\" with\n value \"linus\" in it, and replace its \"url\" variable with\n \"git://...\". If there is no \"remote\" section with such a\n name, create it. For the key matching syntax, I do not\n insist on using \"where\" (I merely used it for continuity\n from the previous discussion). For the comparison operator,\n in addition to the '=' shown above, we would probably want\n to have regexp match (perhaps ':' to emulate \"expr\") as well.\n\nRetrieving a variable:\n\n\t$ cfg --get section.var [where var0 = val0]\n (eg) $ cfg --get remote.url where name = linus\n\nList sections:\n\n\t$ cfg --list section.var\n (eg) $ cfg --list remote.name\n\nSo, an equivalent of \"grep -H URL: .git/remotes/*\" becomes something like:\n\n\tfor name in `cfg --list remote.name`\n do\n \turl=`cfg --get remote.url where name = \"$name\"`\n echo \"$name: URL: $url\"\n\tdone\n"},{"id":"19777","messageId":"Pine.LNX.4.63.0605091321350.7652@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"e3p5om$djs$1@sea.gmane.org","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-09T11:21:56Z","receivedAt":"2006-05-09T11:21:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 May 2006, Jakub Narebski wrote:\n\n> Linus Torvalds wrote:\n> \n> > I would suggest a much more readable format:\n> > \n> > [core]\n> > ...\n> > \n> > [branch \"core\"]\n> > ...\n> > \n> > [remote \"core\"]\n> > ...\n> > \n> > and yes, enforce the + format. We'd turn it internally\n> > into some random internal string format (probably replacing the space with\n> > a dot, and removing the quotes, so it would become \"remote.core.\").\n> \n> I'm all for it. Nice compromise of [branch.\"miXedCaps\"] and [\"miXedCaps\"],\n> human readable end editable, and easy parsable.\n\nOkay, to summarize what people proposed (and that I remember):\n\n1) [branch.\"AnY+String\"]\n\n2) multiple [branch]\n\n3) magic +\n\n4) [branch.just/allow-slashes/and-dashes]\n\n5) the \" for \" notation\n\nOf all these, only (5) is backwards compatible, but it is also the only \none where you have to type the branch name over and over again.\n\nHowever, the old gits do not really know what to do with the [branch] \nsection anyway, so you could consider (2) (and (4), if you do not have \nbranch names with slashes and/or dashes) backwards-compatible, because git \nwill continue to work -- ignoring the funny entries.\n\n(1) and (3) definitely would make an old git choke.\n\nNow, for the ease of use:\n\n(1), (3) and (4) are in the same league of easiness (except maybe that you \nhave to keep in mind to extra-quote in shell scripts with (1) and (3)), \n(2) is especially good for people with a database mindset, and (5) is \nannoying as hell.\n\nNow, for the ease of implementation:\n\n(1) and (3) are in the same league, they have to change the way the config \nis parsed as well as make downcasing conditional in repo-config. (2) is \nobviously hardest of all. (4) is very easy (one line in config.c), and (5) \neasiest (nothing to do).\n\nNow, for the versatility, i.e. what you can express with the syntax:\n\nThe same for all (except for (4) which has very weak restrictions on the \nbranch name).\n\nOh, I completely forgot about another proposal: (6) subkeys (something \nlike \"url[branchname] = blablabla\"). It has about the same effects as (1) \nor (3).\n\nAnother thing: I completely ignored the case sensitivity. Because it is \nirrelevant. Why? Because you do not have two branches which are only \ndifferent by case-ness. It is confusing, and that's why. And you don't \nneed to handle the case specially, because the comparison is done by \ndowncasing anyway.\n\nObviously, I deem (4) the best solution ATM, because it has all the \nexpressability needed, while being the simplest.\n\nCiao,\nDscho\n"},{"id":"19778","messageId":"20060509112641.GB3228@admingilde.org","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605082007100.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-05-09T11:26:41Z","receivedAt":"2006-05-09T11:26:41Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, May 08, 2006 at 08:08:41PM -0700, Linus Torvalds wrote:\n> > What's the advantage of section quotation marks over just allowing these\n> > characters in regular section names? To be specific, what is wrong with:\n> > \n> > [jc/show-branch-dense]\n> \n> This would _suck_\n> \n> What if you have a branch called \"core\"? Not all all unlikely. \n> \n> Think about what a section like\n> \n> \t[core]\n> \n> really means.\n> \n> Plus I really want to not be case sensitive by default. Case sensitivity \n> really is _not_ normal for this kind of config file syntax.\n\nSo why is everybody trying to munch all branch related data into\none .ini style config file?\n\nwhy not simply use the mechanisms we use elsewhere and build something\nlike our remotes or the new HEAD file?\n\n-- \nMartin Waitz\n"},{"id":"19779","messageId":"Pine.LNX.4.63.0605091331000.10174@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"20060509112641.GB3228@admingilde.org","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-09T11:34:19Z","receivedAt":"2006-05-09T11:34:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 May 2006, Martin Waitz wrote:\n\n> So why is everybody trying to munch all branch related data into\n> one .ini style config file?\n> \n> why not simply use the mechanisms we use elsewhere and build something\n> like our remotes or the new HEAD file?\n\nBecause it is good to have one consistent tool to query/update what makes \nup the configuration. Of course, we really could go about it like M$ who \ninvent a hundred an twenty three ways to do the same thing, all with their \nown set of bugs.\n\nI admit that repo-config has not been as stable as it could have been. \nThat was my fault, certainly. But with the help of the list, it has become \nmore stable.\n\nNow, if we decide upon a totally different config format, okay, that's \nwhat it takes. But please let's not have several different formats \n*again*.\n\nCiao,\nDscho\n"},{"id":"19786","messageId":"Pine.LNX.4.64.0605090822150.3718@g5.osdl.org","threadId":"4098","inReplyTo":"Pine.LNX.4.63.0605091321350.7652@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-09T15:29:50Z","receivedAt":"2006-05-09T15:29:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, Johannes Schindelin wrote:\n> \n> Okay, to summarize what people proposed (and that I remember):\n> \n> 1) [branch.\"AnY+String\"]\n\nIf we really change the syntax, I would oppose the \".\". I realize I may \nhave used it myself, and I think it would be good _internally_, but I \nthink the syntax would be\n\n\t[branch \"Any+String\"]\n\nwhich looks a lot more readable. Ie just a space (or, perhaps, \"any \ncombination of spaces and tabs\").\n\n> 4) [branch.just/allow-slashes/and-dashes]\n\nSame here. If we break old parsers anyway, the \".\" has no redeeming \nvalue. You'd use it when _scripting_ stuff, but not anywhere else.\n\nSo in both cases, the above would turn into the _variable_ called \n\"branch.Any+String/and-dashes.\" internally, and things that used \"git \nrepo-config\" would say it that way, but the config file format should be \nhuman-readable.\n\nWe already do that human-readability thing. We say\n\n\t[core]\n\t\tname = Linus Torvalds\n\t\temail = random\n\nbut we turn it internally into\n\n\tcore.name ->\t\"Linus Torvalds\"\n\tcore.email ->\t\"random\"\n\nand that's also the format you use for \"git repo-config\". Similarly, \nhaving\n\n\t[branch \"master\"]\n\t\tremote = git://....\n\nin the config file should - for exactly the same reasons - be turned \n_internally_ into the association\n\n\tbranch.master.remote -> git://...\n\nand for exactly the same reason you'd just use\n\n\tgit repo-config set branch.master.remote \"git://...\"\n\non the command line.\n\nIOW, we _already_ do not match the internal and command line with the \nactal human-readable syntax.\n\n\t\t\tLinus\n"},{"id":"19787","messageId":"7vzmhr3wje.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"Pine.LNX.4.63.0605091321350.7652@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-09T18:03:49Z","receivedAt":"2006-05-09T18:03:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Okay, to summarize what people proposed (and that I remember):\n>\n> 1) [branch.\"AnY+String\"]\n>\n> 2) multiple [branch]\n>\n> 3) magic +\n>\n> 4) [branch.just/allow-slashes/and-dashes]\n>\n> 5) the \" for \" notation\n\nThanks for a nice summary.\n\n> Now, for the ease of use:\n>\n> (1), (3) and (4) are in the same league of easiness (except maybe that you \n> have to keep in mind to extra-quote in shell scripts with (1) and (3)), \n> (2) is especially good for people with a database mindset, and (5) is \n> annoying as hell.\n\nOne thing you might want to consider is variable types and\ndefault values (eh, that makes two).\n\nWhen Linus first introduced the config mechanism, he made it so\nthat a loosely coupled set of programs can take the \"Why should\nI care about other programs configuration\" attitude, and\nactively encouraged to do so by allowing custom config parsers\ninherit from the default parser, like the way git_diff_config()\nfalls back on git_default_config() when it does not recognize\nthe variable.\n\nIt is quite a good design for most uses, except that it made it\ninconvenient to implement things like \"git-repo-config -l\" and\n\"git-var -l\". The point of this design _is_ that they cannot\nknow what the set of possible variables, their types and the\ndefault values when missing are, so by design the script that\nused \"git-var -l | grep\" to read the configuration needed to\nknow that a boolean can be denoted by existence, value set to\nzero or non-zero integer, or string \"true\"/\"false\" (i.e.\n\"filemode\", \"filemode=1\", and \"filemode = true\" mean the same\nthing; BTW I think we would probably want to add \"yes\"/\"no\"\nhere).\n\nLater it was made easier to use by Pasky with \"repo-config --type\"\noption. The caller supplies the name of the variable and the\ntype and repo-config gets the value -- the caller knows what it\nwants to use, so having it to know what type of things it is\ninterested in is not so bad, so the type problem was practically\nsolved. But it still feels somewhat hacky.\n\nWith (2) and (5), we have a bound set of \"se.ct.ion.variable\";\nwe could enumerate the variables we care about, define what they\nmean and what their types and default values are (we need to do\nthat for Documentation/config.txt anyway). With many parts of\nthe standalone git plumbing programs migrating into builtins, I\nthink it is not a bad idea to have a central table of all the\nconfiguration variables that the core knows about. Porcelains\nand scripts could define customized tables that describe the\nsections/variables they also want to see and act on in the\nconfiguration file, and call git-repo-config with that table as\nan optional parameter.\n\n> Now, for the ease of implementation:\n>\n> (1) and (3) are in the same league, they have to change the way the config \n> is parsed as well as make downcasing conditional in repo-config. (2) is \n> obviously hardest of all. (4) is very easy (one line in config.c), and (5) \n> easiest (nothing to do).\n>\n> Now, for the versatility, i.e. what you can express with the syntax:\n>...\n> Obviously, I deem (4) the best solution ATM, because it has all the \n> expressability needed, while being the simplest.\n\nIf we are shooting for \"let's not do this again\", I do not think\n(4) without some quoting convention is good enough. Today, we\nare talking about branch names so we could give them artificial\nlimits, which could be weaker than what we already have on the\nbranch names, but we would later regret that, when we start\nwanting to have other names in the configuration (e.g. people's\nnames).\n"},{"id":"19789","messageId":"Pine.LNX.4.64.0605091215340.3718@g5.osdl.org","threadId":"4098","inReplyTo":"7vzmhr3wje.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-09T19:24:02Z","receivedAt":"2006-05-09T19:24:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, Junio C Hamano wrote:\n> \n> If we are shooting for \"let's not do this again\", I do not think\n> (4) without some quoting convention is good enough. Today, we\n> are talking about branch names so we could give them artificial\n> limits, which could be weaker than what we already have on the\n> branch names, but we would later regret that, when we start\n> wanting to have other names in the configuration (e.g. people's\n> names).\n\nHere's my suggestion as a patch.\n\nNOTE! This patch could be applied right now, and to all the branches (to\nmake 1.x, 1.2.x and 1.3.x all support the _syntax_). Even if nothing \nactually uses it.\n\nIt just makes the syntax be\n\n\t[section+\"\"]\n\nwhere the only rule for \"randomstring\" is that it can't contain a newline, \nand if you really want to insert a double-quote, you do it with \\\".\n\nIt turns that into the section name \"secion.randomstring\".\n\nSo you could use this for things like\n\n\t[email \"torvalds@osdl.org\"]\n\t\tname = Linus Torvalds\n\nif you wanted to do the \"email->name\" conversion as part of the config \nfile format (I'm not claiming that is sensible, I'm just giving it as an \ninsane example). That would show up as the association\n\n\temail.torvalds@osdl.org.name -> Linus Torvalds\n\nwhich is easy to parse (the \".\" in the email _looks_ ambiguous, but it \nisn't: you know that there will always be a single key-name, so you find \nthe key name with \"strrchr(name, '.')\" and things are entirely \nunambiguous).\n\nNow, it doesn't do any repo-config stuff, since the whole point of this is \nto make this a legal syntax, not actually start _using_ it yet. If people \nthink this is an acceptable syntax, then pls apply to everything, and \nworry about usage later.\n\n\t\tLinus\n\n---\ndiff --git a/config.c b/config.c\nindex 0f518c9..f3b74e0 100644\n--- a/config.c\n+++ b/config.c\n@@ -134,6 +134,41 @@ static int get_value(config_fn_t fn, cha\n \treturn fn(name, value);\n }\n \n+static int get_extended_base_var(char *name, int baselen, int c)\n+{\n+\tdo {\n+\t\tif (c == '\\n')\n+\t\t\treturn -1;\n+\t\tc = get_next_char();\n+\t} while (isspace(c));\n+\n+\t/* We require the format to be '[base \"extension\"]' */\n+\tif (c != '\"')\n+\t\treturn -1;\n+\tname[baselen++] = '.';\n+\n+\tfor (;;) {\n+\t\tint c = get_next_char();\n+\t\tif (c == '\\n')\n+\t\t\treturn -1;\n+\t\tif (c == '\"')\n+\t\t\tbreak;\n+\t\tif (c == '\\\\') {\n+\t\t\tc = get_next_char();\n+\t\t\tif (c == '\\n')\n+\t\t\t\treturn -1;\n+\t\t}\n+\t\tname[baselen++] = c;\n+\t\tif (baselen > MAXNAME / 2)\n+\t\t\treturn -1;\n+\t}\n+\n+\t/* Final ']' */\n+\tif (get_next_char() != ']')\n+\t\treturn -1;\n+\treturn baselen;\n+}\n+\n static int get_base_var(char *name)\n {\n \tint baselen = 0;\n@@ -144,6 +179,8 @@ static int get_base_var(char *name)\n \t\t\treturn -1;\n \t\tif (c == ']')\n \t\t\treturn baselen;\n+\t\tif (isspace(c))\n+\t\t\treturn get_extended_base_var(name, baselen, c);\n \t\tif (!isalnum(c) && c != '.')\n \t\t\treturn -1;\n \t\tif (baselen > MAXNAME / 2)\n"},{"id":"19793","messageId":"BAYC1-PASMTP02C02EAC2F64AC00BB5801AEA90@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605091215340.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-09T19:44:59Z","receivedAt":"2006-05-09T19:44:59Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 9 May 2006 12:24:02 -0700 (PDT)\nLinus Torvalds wrote:\n\n> NOTE! This patch could be applied right now, and to all the branches (to\n> make 1.x, 1.2.x and 1.3.x all support the _syntax_). Even if nothing \n> actually uses it.\n> \n> It just makes the syntax be\n> \n> \t[section+\"\"]\n> \n> where the only rule for \"randomstring\" is that it can't contain a newline, \n> and if you really want to insert a double-quote, you do it with \\\".\n\nLightly tested here. Looks good.\n\nSean\n"},{"id":"19801","messageId":"BAYC1-PASMTP04D623089E043F1C792A37AEA90@CEZ.ICE","threadId":"4098","inReplyTo":"BAYC1-PASMTP02C02EAC2F64AC00BB5801AEA90@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-09T22:09:55Z","receivedAt":"2006-05-09T22:09:55Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 9 May 2006 15:44:59 -0400\nsean wrote:\n\n> On Tue, 9 May 2006 12:24:02 -0700 (PDT)\n> Linus Torvalds wrote:\n> \n> > NOTE! This patch could be applied right now, and to all the branches (to\n> > make 1.x, 1.2.x and 1.3.x all support the _syntax_). Even if nothing \n> > actually uses it.\n> > \n> > It just makes the syntax be\n> > \n> > \t[section+\"\"]\n> > \n> > where the only rule for \"randomstring\" is that it can't contain a newline, \n> > and if you really want to insert a double-quote, you do it with \\\".\n> \n> Lightly tested here. Looks good.\n> \n\nLinus,\n\nI really tried to like your patch ;o) But it breaks the repo-config command\nline and causes mixing of some branches using old style [branch.xyz] and new\nstyle [branch \"XYZ\"] which just doesn't seem to be the right thing to do.\n\nThe following patch produced for sake of discussion just allows section\nheaders to contain whatever characters are needed to get the job done.\n\ngit-repo-config works properly with no further need of change. Section\nheaders become case sensitive but key identifiers within sections do not.\nAFAIK there should be no backward compatibility issues with regard to\ncase sensitivity. All tests pass after having been fixed up to remove\nthe assumption that section names are case insensitive.\n\nThe syntax is:\n\n []\n\nHere's how your example would look in this style:\n\n [email.torvalds@osdl.org]\n name = Linus Torvalds\n\nAnd there's no strange syntax needed with repo-config to set and get it:\n\n $ git repo-config email.torvalds@osdl.org.name\n Linus Torvalds\n\nand just to show that key names are still case insensitive:\n\n $ git repo-config email.torvalds@osdl.org.NAME\n Linus Torvalds\n\nSetting new sections is unambiguous from the command line and\ndoesn't have to decide whether to use the [branch \"\"] or\n[branch.section.name] format.\n\n $ git repo-config branch.branch.x y\n $ git repo-config branch.WonkKY.x y\n $ git repo-config --get-regexp branch.\\*\n branch.branch.x y\n branch.WonkKY.x y\n\n [email.torvalds@osdl.org]\n name = Linus Torvalds\n [branch.branch]\n x = y\n [branch.WonkKY]\n x = y\n\nSean\n---\n\n config.c | 11 +++++++----\n repo-config.c | 8 ++++----\n t/t1300-repo-config.sh | 38 ++++++++++++++++++++++----------------\n 3 files changed, 33 insertions(+), 24 deletions(-)\n\ndiff --git a/config.c b/config.c\nindex 0f518c9..5d19ae9 100644\n--- a/config.c\n+++ b/config.c\n@@ -144,11 +144,14 @@ static int get_base_var(char *name)\n \t\t\treturn -1;\n \t\tif (c == ']')\n \t\t\treturn baselen;\n-\t\tif (!isalnum(c) && c != '.')\n-\t\t\treturn -1;\n+\t\tif (c == '\\\\') {\n+\t\t\tc = get_next_char();\n+\t\t\tif (c == '\\n')\n+\t\t\t\treturn -1;\n+\t\t}\n \t\tif (baselen > MAXNAME / 2)\n \t\t\treturn -1;\n-\t\tname[baselen++] = tolower(c);\n+\t\tname[baselen++] = c;\n \t}\n }\n \n@@ -455,7 +458,7 @@ int git_config_set_multivar(const char* \n \t\t\tret = 1;\n \t\t\tgoto out_free;\n \t\t} else\n-\t\t\tstore.key[i] = tolower(key[i]);\n+\t\t\tstore.key[i] = key[i];\n \tstore.key[i] = 0;\n \n \t/*\ndiff --git a/repo-config.c b/repo-config.c\nindex 63eda1b..ba5fbd6 100644\n--- a/repo-config.c\n+++ b/repo-config.c\n@@ -65,11 +65,11 @@ static int show_config(const char* key_,\n static int get_value(const char* key_, const char* regex_)\n {\n \tint i;\n+\tchar *tl;\n \n-\tkey = malloc(strlen(key_)+1);\n-\tfor (i = 0; key_[i]; i++)\n-\t\tkey[i] = tolower(key_[i]);\n-\tkey[i] = 0;\n+\tkey = strdup(key_);\n+\tfor (tl=key+strlen(key)-1; tl >= key && *tl != '.'; --tl)\n+\t\t*tl = tolower(*tl);\n \n \tif (use_key_regexp) {\n \t\tkey_regexp = (regex_t*)malloc(sizeof(regex_t));\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex 7090ea9..f341206 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -23,6 +23,7 @@ git-repo-config Core.Movie BadPhysics\n cat > expect << EOF\n [core]\n \tpenguin = little blue\n+[Core]\n \tMovie = BadPhysics\n EOF\n \n@@ -33,6 +34,7 @@ git-repo-config Cores.WhatEver Second\n cat > expect << EOF\n [core]\n \tpenguin = little blue\n+[Core]\n \tMovie = BadPhysics\n [Cores]\n \tWhatEver = Second\n@@ -45,10 +47,12 @@ git-repo-config CORE.UPPERCASE true\n cat > expect << EOF\n [core]\n \tpenguin = little blue\n+[Core]\n \tMovie = BadPhysics\n-\tUPPERCASE = true\n [Cores]\n \tWhatEver = Second\n+[CORE]\n+\tUPPERCASE = true\n EOF\n \n test_expect_success 'similar section' 'cmp .git/config expect'\n@@ -62,11 +66,13 @@ test_expect_success 'replace with non-ma\n cat > expect << EOF\n [core]\n \tpenguin = very blue\n-\tMovie = BadPhysics\n-\tUPPERCASE = true\n \tpenguin = kingpin\n+[Core]\n+\tMovie = BadPhysics\n [Cores]\n \tWhatEver = Second\n+[CORE]\n+\tUPPERCASE = true\n EOF\n \n test_expect_success 'non-match result' 'cmp .git/config expect'\n@@ -130,7 +136,7 @@ EOF\n \n test_expect_success 'really mean test' 'cmp .git/config expect'\n \n-git-repo-config nextsection.nonewline wow\n+git-repo-config nextSection.nonewline wow\n \n cat > expect << EOF\n [beta] ; silly comment # another comment\n@@ -160,7 +166,7 @@ EOF\n \n test_expect_success 'unset' 'cmp .git/config expect'\n \n-git-repo-config nextsection.NoNewLine \"wow2 for me\" \"for me$\"\n+git-repo-config nextSection.NoNewLine \"wow2 for me\" \"for me$\"\n \n cat > expect << EOF\n [beta] ; silly comment # another comment\n@@ -176,18 +182,18 @@ EOF\n test_expect_success 'multivar' 'cmp .git/config expect'\n \n test_expect_success 'non-match' \\\n-\t'git-repo-config --get nextsection.nonewline !for'\n+\t'git-repo-config --get nextSection.nonewline !for'\n \n test_expect_success 'non-match value' \\\n-\t'test wow = $(git-repo-config --get nextsection.nonewline !for)'\n+\t'test wow = $(git-repo-config --get nextSection.nonewline !for)'\n \n test_expect_failure 'ambiguous get' \\\n-\t'git-repo-config --get nextsection.nonewline'\n+\t'git-repo-config --get nextSection.nonewline'\n \n test_expect_success 'get multivar' \\\n-\t'git-repo-config --get-all nextsection.nonewline'\n+\t'git-repo-config --get-all nextSection.nonewline'\n \n-git-repo-config nextsection.nonewline \"wow3\" \"wow$\"\n+git-repo-config nextSection.nonewline \"wow3\" \"wow$\"\n \n cat > expect << EOF\n [beta] ; silly comment # another comment\n@@ -202,15 +208,15 @@ EOF\n \n test_expect_success 'multivar replace' 'cmp .git/config expect'\n \n-test_expect_failure 'ambiguous value' 'git-repo-config nextsection.nonewline'\n+test_expect_failure 'ambiguous value' 'git-repo-config nextSection.nonewline'\n \n test_expect_failure 'ambiguous unset' \\\n-\t'git-repo-config --unset nextsection.nonewline'\n+\t'git-repo-config --unset nextSection.nonewline'\n \n test_expect_failure 'invalid unset' \\\n-\t'git-repo-config --unset somesection.nonewline'\n+\t'git-repo-config --unset someSection.nonewline'\n \n-git-repo-config --unset nextsection.nonewline \"wow3$\"\n+git-repo-config --unset nextSection.nonewline \"wow3$\"\n \n cat > expect << EOF\n [beta] ; silly comment # another comment\n@@ -249,7 +255,7 @@ test_expect_success 'hierarchical sectio\n \n cat > expect << EOF\n beta.noindent=sillyValue\n-nextsection.nonewline=wow2 for me\n+nextSection.nonewline=wow2 for me\n 123456.a123=987\n 1.2.3.alpha=beta\n EOF\n@@ -259,7 +265,7 @@ test_expect_success 'working --list' \\\n \n cat > expect << EOF\n beta.noindent sillyValue\n-nextsection.nonewline wow2 for me\n+nextSection.nonewline wow2 for me\n EOF\n \n test_expect_success '--get-regexp' \\\n"},{"id":"19805","messageId":"7vu07y252m.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"BAYC1-PASMTP04D623089E043F1C792A37AEA90@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-09T22:42:25Z","receivedAt":"2006-05-09T22:42:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"sean writes:\n\n> The syntax is:\n>\n> []\n\nDoes this mean you can have anything other than LF and ']'?\n\n> Here's how your example would look in this style:\n>\n> [email.torvalds@osdl.org]\n> name = Linus Torvalds\n\nHow does a program (not a script, but git_config() users) get\nthat value and parse it? \n"},{"id":"19807","messageId":"BAYC1-PASMTP124D39CDBCFC35738102D0AEA90@CEZ.ICE","threadId":"4098","inReplyTo":"7vu07y252m.fsf@assigned-by-dhcp.cox.net","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-09T22:45:19Z","receivedAt":"2006-05-09T22:45:19Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 09 May 2006 15:42:25 -0700\nJunio C Hamano wrote:\n\n> sean writes:\n> \n> > The syntax is:\n> >\n> > []\n> \n> Does this mean you can have anything other than LF and ']'?\n\nAnything but LF; how's this for ugly:\n\n [\"hello Worl\\]d \\\\backslash]\n\n> > Here's how your example would look in this style:\n> >\n> > [email.torvalds@osdl.org]\n> > name = Linus Torvalds\n> \n> How does a program (not a script, but git_config() users) get\n> that value and parse it? \n\nThe same way they do now. For instance git-repo-config processes\nthe config file using the same get_config() + callback as usual. The\nonly issue is that they should no longer cast everything to lower first.\n\nSean\n"},{"id":"19808","messageId":"BAYC1-PASMTP0585D8EE00CAB2D1AD8361AEA90@CEZ.ICE","threadId":"4098","inReplyTo":"20060509184519.5a707231.seanlkml@sympatico.ca","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-09T23:07:08Z","receivedAt":"2006-05-09T23:07:08Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 9 May 2006 18:45:19 -0400\nsean wrote:\n\n> > How does a program (not a script, but git_config() users) get\n> > that value and parse it? \n> \n> The same way they do now. For instance git-repo-config processes\n> the config file using the same get_config() + callback as usual. The\n> only issue is that they should no longer cast everything to lower first.\n\nJunio,\n\nSorry I see what you're driving at; how does a program break the section\nname into it's constituent pieces. I glossed over this issue because\nit's exactly the same between Linus' proposal and mine. The answer is,\nthey really can't, with either proposal.\n\nAll you can count on (by convention) is that there is an initial segment\nthat is terminated by a period; and a final segment that starts with a\nperiod, and everything in between is an opaque unit.\n\n section..keyname value\n\nAlthough the initial \"section.\" isn't currently enforced (but easily\ncould be). Actually i didn't yank out the bit from config.c that\nvalidates the keyname, so without an additional patch the only way\nto enter the extended names is by manual editing of the .git/config.\n\nSean\n"},{"id":"19809","messageId":"1147217031.21611.4.camel@dv","threadId":"4098","inReplyTo":"20060509184519.5a707231.seanlkml@sympatico.ca","subject":"Re: Implementing branch attributes in git config","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-09T23:23:51Z","receivedAt":"2006-05-09T23:23:51Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2006-05-09 at 18:45 -0400, sean wrote:\n> On Tue, 09 May 2006 15:42:25 -0700\n> Junio C Hamano wrote:\n> > Does this mean you can have anything other than LF and ']'?\n> \n> Anything but LF; how's this for ugly:\n> \n> [\"hello Worl\\]d \\\\backslash]\n\nActually, LF is already handled just fine in the value part:\n\n[proski@dv .git]$ git-repo-config s1.k1 $'v1\\nv2'\n[proski@dv .git]$ grep [sk]1 config \n[s1]\n k1 = v1\\nv2\n\nNote that quoting doesn't solve this problem (unless multi-line section\nheaders are allowed), but backslash escaping does.\n\nBut I guess everybody prefers quotes for their friendly look.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"19810","messageId":"Pine.LNX.4.64.0605091543100.3718@g5.osdl.org","threadId":"4098","inReplyTo":"BAYC1-PASMTP04D623089E043F1C792A37AEA90@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T00:17:58Z","receivedAt":"2006-05-10T00:17:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, sean wrote:\n>\n> I really tried to like your patch ;o) But it breaks the repo-config command\n> line and causes mixing of some branches using old style [branch.xyz] and new\n> style [branch \"XYZ\"] which just doesn't seem to be the right thing to do.\n\nWell, obviously it's _simpler_ to have the machine-readable format as-is, \nand say \"don't try to make it human-readable\". But the repo-config patch \nto make it human-readable isn't that hard.\n\nAnd it's _not_ that hard to make repo-config do the right thing.\n\nHere's a pretty lightly tested patch (on top of my previous one) that does \nexactly that.\n\n(The first part just fixes an indentation bug)\n\n\t\tLinus\n---\ndiff --git a/config.c b/config.c\nindex f3b74e0..12c51b1 100644\n--- a/config.c\n+++ b/config.c\n@@ -372,10 +372,12 @@ static int store_aux(const char* key, co\n \t\t\tstore.offset[store.seen] = ftell(config_file);\n \t\t\tstore.state = KEY_SEEN;\n \t\t\tstore.seen++;\n-\t\t} else if (strrchr(key, '.') - key == store.baselen &&\n+\t\t} else {\n+\t\t\tif (strrchr(key, '.') - key == store.baselen &&\n \t\t\t !strncmp(key, store.key, store.baselen)) {\n \t\t\t\t\tstore.state = SECTION_SEEN;\n \t\t\t\t\tstore.offset[store.seen] = ftell(config_file);\n+\t\t\t}\n \t\t}\n \t}\n \treturn 0;\n@@ -383,8 +385,30 @@ static int store_aux(const char* key, co\n \n static void store_write_section(int fd, const char* key)\n {\n+\tconst char *dot = strchr(key, '.');\n+\tint len1 = store.baselen, len2 = -1;\n+\n+\tdot = strchr(key, '.');\n+\tif (dot) {\n+\t\tint dotlen = dot - key;\n+\t\tif (dotlen < len1) {\n+\t\t\tlen2 = len1 - dotlen - 1;\n+\t\t\tlen1 = dotlen;\n+\t\t}\n+\t}\n+\t\t\t\n \twrite(fd, \"[\", 1);\n-\twrite(fd, key, store.baselen);\n+\twrite(fd, key, len1);\n+\tif (len2 >= 0) {\n+\t\twrite(fd, \" \\\"\", 2);\n+\t\twhile (--len2 >= 0) {\n+\t\t\tunsigned char c = *++dot;\n+\t\t\tif (c == '\"')\n+\t\t\t\twrite(fd, \"\\\\\", 1);\n+\t\t\twrite(fd, &c, 1);\n+\t\t}\n+\t\twrite(fd, \"\\\"\", 1);\n+\t}\n \twrite(fd, \"]\\n\", 2);\n }\n \n@@ -458,7 +482,7 @@ int git_config_set(const char* key, cons\n int git_config_set_multivar(const char* key, const char* value,\n \tconst char* value_regex, int multi_replace)\n {\n-\tint i;\n+\tint i, dot;\n \tint fd = -1, in_fd;\n \tint ret;\n \tchar* config_filename = strdup(git_path(\"config\"));\n@@ -483,16 +507,23 @@ int git_config_set_multivar(const char* \n \t * Validate the key and while at it, lower case it for matching.\n \t */\n \tstore.key = (char*)malloc(strlen(key)+1);\n-\tfor (i = 0; key[i]; i++)\n-\t\tif (i != store.baselen &&\n-\t\t\t\t((!isalnum(key[i]) && key[i] != '.') ||\n-\t\t\t\t (i == store.baselen+1 && !isalpha(key[i])))) {\n-\t\t\tfprintf(stderr, \"invalid key: %s\\n\", key);\n-\t\t\tfree(store.key);\n-\t\t\tret = 1;\n-\t\t\tgoto out_free;\n-\t\t} else\n-\t\t\tstore.key[i] = tolower(key[i]);\n+\tdot = 0;\n+\tfor (i = 0; key[i]; i++) {\n+\t\tunsigned char c = key[i];\n+\t\tif (c == '.')\n+\t\t\tdot = 1;\n+\t\t/* Leave the extended basename untouched.. */\n+\t\tif (!dot || i > store.baselen) {\n+\t\t\tif (!isalnum(c) || (i == store.baselen+1 && !isalpha(c))) {\n+\t\t\t\tfprintf(stderr, \"invalid key: %s\\n\", key);\n+\t\t\t\tfree(store.key);\n+\t\t\t\tret = 1;\n+\t\t\t\tgoto out_free;\n+\t\t\t}\n+\t\t\tc = tolower(c);\n+\t\t}\n+\t\tstore.key[i] = c;\n+\t}\n \tstore.key[i] = 0;\n \n \t/*\n"},{"id":"19812","messageId":"BAYC1-PASMTP037EBB0237B35C5F92FB0BAEAE0@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605091543100.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-10T01:08:57Z","receivedAt":"2006-05-10T01:08:57Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 9 May 2006 17:17:58 -0700 (PDT)\nLinus Torvalds wrote:\n\n> And it's _not_ that hard to make repo-config do the right thing.\n> \n> Here's a pretty lightly tested patch (on top of my previous one) that does \n> exactly that.\n\nSo every mutli-part section is going to be of the form:\n\n [section \"big long opaque string\"]\n\nIt seems to handle everything, you have me convinced.\n \nSean\n"},{"id":"19811","messageId":"BAYC1-PASMTP1056CADE82C96CB1DA9AA9AEAE0@CEZ.ICE","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605091543100.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-10T01:38:53Z","receivedAt":"2006-05-10T01:38:53Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 9 May 2006 17:17:58 -0700 (PDT)\nLinus Torvalds wrote:\n\n> Here's a pretty lightly tested patch (on top of my previous one) that does \n> exactly that.\n\nThis patch or something like it is needed for repo-config in order to query\nthe new case sensitive portion of section names. This is on top of your two\npatches:\n\ndiff --git a/repo-config.c b/repo-config.c\nindex 63eda1b..9a9194f 100644\n--- a/repo-config.c\n+++ b/repo-config.c\n@@ -65,11 +65,14 @@ static int show_config(const char* key_,\n static int get_value(const char* key_, const char* regex_)\n {\n \tint i;\n+\tchar *tl;\n+\n+\tkey = strdup(key_);\n+\tfor (tl=key+strlen(key)-1; tl >= key && *tl != '.'; --tl)\n+\t\t*tl = tolower(*tl);\n+\tfor (tl=key; *tl && *tl != '.'; ++tl)\n+\t\t*tl = tolower(*tl);\n \n-\tkey = malloc(strlen(key_)+1);\n-\tfor (i = 0; key_[i]; i++)\n-\t\tkey[i] = tolower(key_[i]);\n-\tkey[i] = 0;\n \n \tif (use_key_regexp) {\n \t\tkey_regexp = (regex_t*)malloc(sizeof(regex_t));\n"},{"id":"19813","messageId":"Pine.LNX.4.64.0605091854380.3718@g5.osdl.org","threadId":"4098","inReplyTo":"BAYC1-PASMTP037EBB0237B35C5F92FB0BAEAE0@CEZ.ICE","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T02:08:45Z","receivedAt":"2006-05-10T02:08:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, sean wrote:\n> On Tue, 9 May 2006 17:17:58 -0700 (PDT)\n> Linus Torvalds wrote:\n> \n> > And it's _not_ that hard to make repo-config do the right thing.\n> > \n> > Here's a pretty lightly tested patch (on top of my previous one) that does \n> > exactly that.\n> \n> So every mutli-part section is going to be of the form:\n> \n> [section \"big long opaque string\"]\n\nThat's what my stupid patch does now. It seems to work well for all cases, \nbut if we were to care, we could have some special heuristics for \ndifferent section names (ie \"if subsection is all lower-case \nalphanumerics, and the section name is one of the following, use the \nold-fashioned format\").\n\nI don't see _why_ we'd ever do that, but we certainly _could_, if it were \nto make more sense that way for some section name.\n\nHowever, if you already use a syntax like\n\n\t[section.subsection]\n\t\tkey = 1\n\nand then do\n\n\tgit-repo-config --replace-all section.subsection.new 2\n\nit will actually keep the old section header, so you'll end up with\n\n\t[section.subsection]\n\t\tkey = 1\n\t\tnew = 2\n\nbut if you create a _new_ subsection (and since subsections are now case \nsensitive, this example is a \"new\" subsection):\n\n\tgit-repo-config --replace-all section.SubSection.new 3\n\nyou will now have\n\n\t[section.subsection]\n\t\tkey = 1\n\t\tnew = 2\n\t[section \"SubSection\"]\n\t\tnew = 3\n\n(ie notice how it did _not_ replace the old \"section.subsection.new\", \nbecause of how this is a _different_ subsection due to the subsectin \nrules, and notice how it will always create the new subsection with \nquotes).\n\nSo you _can_ continue to use the old subsection format, and it will work \nthe way it always did, except for the fact that it would now be deprecated \n(if there were any multi-level users, which I don't think there are), and \nit is now case-sensitive (which makes sense in the new format with \"\" \naround it, but is illogical in the old deprecated one).\n\n> It seems to handle everything, you have me convinced.\n\nHey, it was fun, and the only ugly part was the write-out of the quoted \nformat.\n\nAnd it should be perfectly easy to use. Modulo double-quotes in branch \nnames, you can do trivial things like\n\n\tgit repo-config \"branch.$branchname.remote\" \"git://git.kernel.org/...\"\n\nand it will do the obvious thing.\n\nMy one complaint is that I think we should add an empty line for the case \nwhere we add a new sub-section to the end of a file. That's not a new \nproblem, but that was really the only visually ugly part I noticed during \ntesting.\n\nYou _can_ be user-friendly and machine-parseable at the same time!\n\n\t\t\tLinus\n"},{"id":"19826","messageId":"46a038f90605100019q3b44b87kf49e456668f2e249@mail.gmail.com","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605091854380.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-05-10T07:19:07Z","receivedAt":"2006-05-10T07:19:07Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/10/06, Linus Torvalds wrote:\n> You _can_ be user-friendly and machine-parseable at the same time!\n\nGood one. I'm following this thread with interest, but it feels we've\nbeen attacked by the 'bike shed bug' in the act of redesigning\nWindows.ini.\n\nAs an end-user, I have personally stayed away from the increasingly\ncomplex scheme for remotes waiting for it to settle, and stuck with\nthe old-styled .git/branches stuff which is slam-dunk simple and it\njust works.\n\nThe normal non-branch config options don't need any of this fancy\nstuff. And I think the branches is reasonably well managed as files as\nis done in .git/remotes which is trivial to work on with standard\nshell commands. What I mean is that I can grep them trivially to ask\n\"how many remotes pull from server X\" or from repo Y. Or via rsync.\n\nAlso -- repo config is tricky in the sense of scope. I want all my\n\"dev\" repos of different projects on my laptop to have mostly the same\nconfig but radically different remotes listings.\n\nSo... call me old-styled... but I'm happy with one-file-per-remote.\nWas it broken to start with? Should we restart the track renames\nflameway instead?\n\ncheers,\n\n\n\nmartin\n"},{"id":"19828","messageId":"Pine.LNX.4.63.0605101305560.6240@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"46a038f90605100019q3b44b87kf49e456668f2e249@mail.gmail.com","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-10T11:07:34Z","receivedAt":"2006-05-10T11:07:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 10 May 2006, Martin Langhoff wrote:\n\n> So... call me old-styled... but I'm happy with one-file-per-remote.\n> Was it broken to start with?\n\nDepends on how you look at it. A bunch of files is okay for quick-n-dirty, \nwhere you do not care about locking or consistency or extensibility.\n\nCiao,\nDscho\n"},{"id":"19831","messageId":"Pine.LNX.4.64.0605100823350.3718@g5.osdl.org","threadId":"4098","inReplyTo":"46a038f90605100019q3b44b87kf49e456668f2e249@mail.gmail.com","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T15:37:13Z","receivedAt":"2006-05-10T15:37:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 10 May 2006, Martin Langhoff wrote:\n> \n> Good one. I'm following this thread with interest, but it feels we've\n> been attacked by the 'bike shed bug' in the act of redesigning\n> Windows.ini.\n\nSure. It clearly _is_ a bike shed, which is why I posted patches: I think \nthe way to resolve bike sheds is to \"just do it\". In the kernel, the \ngeneral rule ends up being \"he who writes the code gets to choose how it \ngets done\", because it turns out that there are a lot more people willing \nto _argue_ about code than there are people willing to _write_ it, and \nthus that \"real code wins\" rule actually works very well in practice.\n\nI don't think I've ever really seen an argument where you ended up having \nseriously competing patches. Yes, you can have patches to do things \ndifferent ways, but once you have that, it tends to be pretty easy for the \nmaintainer to just draw a line in the sand. And once one patch has been \naccepted, it's all over.\n\nSo the real problem with \"bike sheds\" is actually when you have a culture \nof arguing, and not enough of a culture of \"just do it\".\n\nIf you have a \"just do it\" culture, bike sheds are often good things. If \nit really _is_ that easy, a bike shed is a perfect opportunity for \nsomebody who isn't all that deeply into a project to make a contribution \nand start feeling more comfy about it. It obviously didn't happen here, \nbut it's definitely true that a lot of people in the kernel get introduced \nto doing patches through various \"trivial\" things.\n\nSo don't knock the bike sheds. It's a BSD term, and I think there's a \n_reason_ why it's a BSD term. Those people seem to sometimes like to argue \nabout theoretical things (or about anything else, for that matter) more \nthan actually getting the damn job done.\n\n> As an end-user, I have personally stayed away from the increasingly\n> complex scheme for remotes waiting for it to settle, and stuck with\n> the old-styled .git/branches stuff which is slam-dunk simple and it\n> just works.\n\nIt does work, and I think it's nice in many ways. It was certainly a good \nway to prototype things.\n\nAt the same time, especially with moving things more to C (or almost any \nother language, for that matter - shell is really pretty special in making \nit _easier_ to have things in individual files), it's in many ways nicer \nto have a more structured representation that has a nice fixed interface \nand a library and known access methods behind it.\n\nAnd I'm personally actually pretty fed up with the .git/branches/ and \n.git/remotes/ thing, partly because I can never remember which file is \nwhich. I had to look at the code of git-parse-remote.sh to remind me which \nhad what semantics. We could remove the old one entirely, of course (and \nno, I don't remember which is which now either), and avoid that particular \nproblem, but it kind of soured me on it. \n\nAnd if we truly have separate files, we should go all the way, and have \nthe good old \"one file, one value\" rule. Which we don't, and which I think \neverybody admits would be horrible for this case for users (even if it \nmight be very nice for scripting).\n\n\t\tLinus\n"},{"id":"19832","messageId":"e3t2sq$4v9$1@sea.gmane.org","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605100823350.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-10T16:03:35Z","receivedAt":"2006-05-10T16:03:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n\n> On Wed, 10 May 2006, Martin Langhoff wrote:\n>> \n>> Good one. I'm following this thread with interest, but it feels we've\n>> been attacked by the 'bike shed bug' in the act of redesigning\n>> Windows.ini.\n[...]\n>> As an end-user, I have personally stayed away from the increasingly\n>> complex scheme for remotes waiting for it to settle, and stuck with\n>> the old-styled .git/branches stuff which is slam-dunk simple and it\n>> just works.\n\n> And I'm personally actually pretty fed up with the .git/branches/ and\n> .git/remotes/ thing, partly because I can never remember which file is\n> which. I had to look at the code of git-parse-remote.sh to remind me which\n> had what semantics. We could remove the old one entirely, of course (and\n> no, I don't remember which is which now either), and avoid that particular\n> problem, but it kind of soured me on it.\n> \n> And if we truly have separate files, we should go all the way, and have\n> the good old \"one file, one value\" rule. Which we don't, and which I think\n> everybody admits would be horrible for this case for users (even if it\n> might be very nice for scripting).\n\nOn one hand the remotes/ (or older branches/) is similar to refs/heads and\nrefs/tags that it contains shortcut names for pulling and pushing. On the\nother hand configuration should belong to configuration.\n\nBesides, AFAICT we did not have the place to have branch specific\nconfiguration (like description, default place to pull from + marking\nbranch as immutable, default place to push to, etc.) and if I understand\ncorrectly branches/ was used for something else. refs/heads/`name` stored\nbranches, including temporary branches which did not need configuration.\n\nI guess that for the time being we can have remotes both in remotes/ and in\nconfig file, plus script to freely transform between them (unless some\nconfig would be unattainable by remotes/ file).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19843","messageId":"46a038f90605101617x1aa9bd2du959ead77ebf61795@mail.gmail.com","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605100823350.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-05-10T23:17:48Z","receivedAt":"2006-05-10T23:17:48Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/11/06, Linus Torvalds wrote:\n> Sure. It clearly _is_ a bike shed, which is why I posted patches: I think\n> the way to resolve bike sheds is to \"just do it\". In the kernel, the\n\nthere's no disputing that!\n\n> So don't knock the bike sheds. It's a BSD term, and I think there's a\n> _reason_ why it's a BSD term. Those people seem to sometimes like to\n\nApologies -- I didn't want to know it, but I do wonder what the gain\nbehind the change is. It seems to me that it would be a bad idea to\nstore refs in the config file and, in my mind at least, branch info is\ncloser to refs.\n\n> > As an end-user, I have personally stayed away from the increasingly\n> > complex scheme for remotes waiting for it to settle, and stuck with\n> > the old-styled .git/branches stuff which is slam-dunk simple and it\n> > just works.\n>\n> It does work, and I think it's nice in many ways. It was certainly a good\n> way to prototype things.\n>\n> At the same time, especially with moving things more to C (or almost any\n> other language, for that matter - shell is really pretty special in making\n> it _easier_ to have things in individual files), it's in many ways nicer\n> to have a more structured representation that has a nice fixed interface\n> and a library and known access methods behind it.\n\nBut it is a bit of a loss for perl/shell porcelains, and for users\nthat abuse the contents of .git directly on a regular basis...\n\nthere's nothing to stop us from having a structured representation of\nwhat's in .git/branches/\n\n> And I'm personally actually pretty fed up with the .git/branches/ and\n> .git/remotes/ thing, partly because I can never remember which file is\n> which. I had to look at the code of git-parse-remote.sh to remind me\n\nAgreed, it's a mess, but I suspect it's still there to support cogito.\nIn keeping with the 'talk code' ethos, I'll work on adding support for\n.git/remotes in cogito.\n\n> And if we truly have separate files, we should go all the way, and have\n> the good old \"one file, one value\" rule.\n\nWhat about one semantics, one file? So far we have had 3 semantics:\ngit config, remotes, refs. And git config has been mostly\nproject-indepentent. In fact, I have been copying it across my\ncheckouts of different, unrelated projects. You just don't do that\nwith remotes or refs.\n\ncheers,\n\n\nmartin\n"},{"id":"19844","messageId":"Pine.LNX.4.64.0605101629230.3718@g5.osdl.org","threadId":"4098","inReplyTo":"46a038f90605101617x1aa9bd2du959ead77ebf61795@mail.gmail.com","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T23:55:41Z","receivedAt":"2006-05-10T23:55:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 11 May 2006, Martin Langhoff wrote:\n> \n> Apologies -- I didn't want to know it, but I do wonder what the gain\n> behind the change is.\n\nI think we can do better in a few pretty important regards:\n\n - having the information in one place. I agree that the multi-file \n approach works fine for shell scripts (although I disagree that the new \n one would be harder - you just use git-repo-config instead), but I \n think it's quite confusing from a new user perspective.\n\n I bet that even without any tools, new users can be told to just open \n \".git/config\", and guess how hard a time they would have to add a new \n branch, if they already had one that said\n\n\t[branch \"origin\"]\n\t\tremote = git://git.kernel.org/pub/scm/git/git.git\n\t\tbranch master\n\n which would tell you that the local branch \"origin\" is really branch\n \"master\" at that remote git repository.\n\n Yeah, I'm not sure what the actual config rules would be, but think it \n would be a hell of a lot more intuitive than what we have now. \n\n What we have now _works_. It works really well. No question about that. \n It's just pretty hard to explain. The above syntax wouldn't even need \n any explanation. You could just tell people to look into their config \n files.\n\n - I think we'll have a much easier time (from a purely technical angle) \n to add special attributes to the local branches. Add a \"read-only\" \n specifier? It's _obvious_:\n\n\t[branch \"origin\"] \n\t\tremote = git://git.kernel.org/pub/scm/git/git.git\n\t\tbranch master\n\t\treadonly\n\n and it's absolutely trivial to parse. And part of the important thing \n is that this all makes 100% sense EVEN IF IT'S NOT A REMOTE REPO!\n\n So imagine that it's a purely local branch, but you want to protect it. \n Solution?\n\n\t[branch \"July Snapshot\"]\n\t\treadonly\n\n and you're done. In contrast, even if you ended up just extending the \n file format for the .git/remotes/July\\ Snapshot file, and just added a \n \"readonly\" line to it, it wouldn't make _sense_. Whaa? \"remotes\"? In \n contrast, in the .git/config file, it makes a ton of sense, and in fact \n it's totally obvious.\n\n (Actually, we should probably have the .git/config file syntax separate \n local branches like \"master\" from remote branches like \"origin\", so it \n might be more like\n\n\t[remote \"origin\"]\n\t\turl = git://git.kernel.org/pub/scm/git/git.git\n\n which just tells that the _word_ \"origin\" corresponds to a \n shorthand for a particular remote repository\n\n\t[branch \"origin\"]\n\t\tremote = origin\n\t\tbranch = master\n\n or something to show that your _local_ branch named \"origin\" \n corresponds to a particular remote (which could be a shorthand like the \n above, or just spelled out), and a particular branch _at_ that remote \n repository)\n\n Anyway, the point is, I think our current .git/remotes/xyzzy files \n actually mix two different concepts, and they also end up doing it \n pretty badly. They _work_, but because of the mix-ups, they aren't all \n that they could be, and it's fundamentally impossible to make them so, \n because the mixup really is that \"origin\" means TWO DIFFERENT THINGS \n (the local branch, and the remote that it corresponds to)\n\n - Finally, I think it opens the possibility for some other things. For \n example, once you accept that different branches might want attributes \n like \"readonly\", you realize that some other attributes also make \n sense. Like adding the default pull source per local branch, etc.\n\nAgain, I'm not saying that we can't work with the .git/remotes/ files. But \nI think it gets increasingly ugly, and the confusion gets increasingly \nworse.\n\n> But it is a bit of a loss for perl/shell porcelains, and for users\n> that abuse the contents of .git directly on a regular basis...\n\nI really disagree. \n\nThe .git/config file is _easier_ to edit by hand than the remotes. It's \neasier to copy-paste within one file than it is to work with two different \nfiles (and let's face it, copy-paste is usually what at least I would do \nfor something like this). And it's _easier_ to just always open one file, \nand search within that one, than try to remember what file it was.\n\nNow, C programs can very easily use the config library, and shell programs \ncan equally easily query the variables with \"git repo-config\". I really \ndoubt it's very hard for perl either, but I'm not a perl person, so maybe \nI don't see why this is hard.\n\n\t\tLinus\n"},{"id":"19845","messageId":"Pine.LNX.4.64.0605101656110.3718@g5.osdl.org","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605101629230.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-11T00:11:17Z","receivedAt":"2006-05-11T00:11:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 10 May 2006, Linus Torvalds wrote:\n>\n> - having the information in one place. I agree that the multi-file \n> approach works fine for shell scripts (although I disagree that the new \n> one would be harder - you just use git-repo-config instead), but I \n> think it's quite confusing from a new user perspective.\n\nBtw, I seriously believe that git has come to the point where we've licked \nthe real technical issues. Stability hasn't been a concern for the last \nyear - and even something as seriously as a repacking bug causing a \nSIGSEGV (yesterday) was actually basically designed to not be able to \ncause problems. The repack failed, and nothing happened to the old data. \nIt was scary, but it wasn't \"bad\".\n\nThe last performance problem was a stupid one-liner, where one of the \nshell scripts didn't use the \"--aggressive\" flag for doing the trivial \nthree-way merge, so it ended up forking and executing the \"merge-one-file\" \nshell script for 4500+ files for one unfortunate project that had a \nstrange workflow. Adding the \"--aggressive\" flag took a 5-minute (where \nall of the time was spent in a shell script basically doing nothing) thing \ndown to under a second.\n\nSo git should kick butt in performance, scale very well, and seems to take \nless disk space than just about anybody else. \n\nSo what do people actually _complain_ about? \n\nI don't think we've seen a serious complaint lately that hasn't been about \nnice user interface and/or documentation. Anybody? \n\nSo as far as I can tell, the #1 issue is that \"new user\" experience. You \ncan pretty much forget about anything else. Working with git in a \ndistributed manner is really easy and efficient, but from the comments \nI've seen, it's not always easy and obvious how to get to that point. \n\nCreating a remote repository and filling it. And being able to understand \nwhat the local vs remote branches actually _mean_. And I think our current \n.git/remotes/ thing is a part of that. It's not exactly user _hostile_, \nbut it's very much \"implementation friendly, and doesn't care about the \nuser\". So I think .git/config can help us there.\n\nI also think we could do with a few scripts to just do setup of a remote \nrepo:\n\n\tgit remote clone \n\tgit remote branch [-D]\n\tgit remote fsck \n\tgit remote repack -a -d\n\nwhich would all basically boil down to \"ssh to the remote address, cd into \nthat directory, and do the named git command there\" (well, not clone: \ndoing a remote clone involves doing a mkdir/git-init-db/git-receive-pack \nremotely, and doing a git-send-pack locally, so some of them would be \nabout doing things _both_ locally and remotely).\n\nAnd documentation.\n\nNow, I don't do documentation, and I really think somebody else could do \nthe whole \"git remote \" thing too. It _should_ really be pretty \ntrivial. My real point is that almost none of this is about technology, \nand it's much more about trying to put a whole lot of lipstick on this \npig. We have _got_ the technology already, and I think most people will \nagree git is doing pretty damn well there.\n\nBecause I really think the pig is quite charming, just sometimes you see \nsome of its boorish sides right now..\n\n(Or should that be \"boarish\", when we talk about pigs? ;)\n\n\t\tLinus\n"},{"id":"19846","messageId":"46a038f90605101713n506207aem1326cd2bf5a1f861@mail.gmail.com","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605101629230.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-05-11T00:13:21Z","receivedAt":"2006-05-11T00:13:21Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/11/06, Linus Torvalds wrote:\n> [branch \"origin\"]\n> remote = git://git.kernel.org/pub/scm/git/git.git\n> branch master\n\nThis is confusing at first read -- is it branch origin or branch master?\n\n> Anyway, the point is, I think our current .git/remotes/xyzzy files\n> actually mix two different concepts, and they also end up doing it\n> pretty badly. They _work_, but because of the mix-ups, they aren't all\n> that they could be, and it's fundamentally impossible to make them so,\n> because the mixup really is that \"origin\" means TWO DIFFERENT THINGS\n> (the local branch, and the remote that it corresponds to)\n\nAs you say, this needs to be explained/exposed better to the user.\nNow, how about having one .git/config and one .git/branches file?\nDifferent semantics, etc.\n\n> The .git/config file is _easier_ to edit by hand than the remotes. It's\n> easier to copy-paste within one file than it is to work with two\n\nAgreed, but I suspect repo config and branches config travel at\ndifferent speeds. Maybe what this means is that if this happens, we'll\nstart seeing a need for ~/.git/config and /etc/git/config to set\ndefaults (merge.summary=1 for all my repos, core.sharedrepository=1\nfor all the repos on this server) where I now I just mostly copy\n.git/config around.\n\nDoes that make sense?\n\n> I don't see why this is hard.\n\nMust be me... it's not the Perl part... I just do a lot of grep |\nxargs | sed stuff in my daily git usage ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"19847","messageId":"Pine.LNX.4.64.0605102148310.24505@localhost.localdomain","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605101629230.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-05-11T01:53:17Z","receivedAt":"2006-05-11T01:53:17Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 10 May 2006, Linus Torvalds wrote:\n\n> \t[branch \"origin\"]\n> \t\tremote = git://git.kernel.org/pub/scm/git/git.git\n> \t\tbranch master\n\nI totally agree with the principle, but I find the above really \nconfusing. Which \"branch\" means what? At least if it was \"remote_url\" \nand \"remote_branch\" then there wouldn't be any possibility for \nconfusion.\n\n\nNicolas\n"},{"id":"19848","messageId":"e3uk0u$14n$1@sea.gmane.org","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605102148310.24505@localhost.localdomain","subject":"Re: Implementing branch attributes in git config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-11T06:02:07Z","receivedAt":"2006-05-11T06:02:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> On Wed, 10 May 2006, Linus Torvalds wrote:\n> \n>> [branch \"origin\"]\n>> remote = git://git.kernel.org/pub/scm/git/git.git\n>> branch master\n> \n> I totally agree with the principle, but I find the above really\n> confusing. Which \"branch\" means what? At least if it was \"remote_url\"\n> and \"remote_branch\" then there wouldn't be any possibility for\n> confusion.\n\nI'm not sure if remotes shortcuts and configuration (which branches should\nbe pulled, and to which branches) should be in branches configuration. It\nis somewhat confusing. Branches configuration might be used for default\npulling, e.g.\n\n\n[remote \"kernel.org\"]\n url = git://git.kernel.org/pub/scm/git/git.git\n pull = master:origin\n ...\n pull = +pu:pu\n\n[branch \"origin\"]\n pull = kernel.org\n readonly\n\n[branch \"pu\"]\n pull = kernel.org\n readonly\n fast-forward = no\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19849","messageId":"20060511095158.GA23620@coredump.intra.peff.net","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605101656110.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-05-11T09:51:58Z","receivedAt":"2006-05-11T09:51:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 10, 2006 at 05:11:17PM -0700, Linus Torvalds wrote:\n\n> I also think we could do with a few scripts to just do setup of a remote \n> repo:\n> \n> \tgit remote clone \n> \tgit remote branch [-D]\n> \tgit remote fsck \n> \tgit remote repack -a -d\n\nHere's a 'git remote' that handles the easy commands. It makes things\nlike 'git remote origin repack -a -d' do what you expect. The biggest\nproblems are:\n - it only works for ssh remotes\n - it assumes your remote path is a git dir (do we have a usual way of\n deciding between $path and $path/.git?)\n - ssh'ing will mangle your shell quoting in the command arguments\n - the url parsing is somewhat ad-hoc (do we have a usual way of\n parsing urls for shell scripts?)\n\n---\nAdd braindead git-remote script.\n\nThis script is a convenience wrapper for performing remote commands on a\nrepository using ssh.\n\n---\n\n Makefile | 2 +-\n git-remote.sh | 19 +++++++++++++++++++\n 2 files changed, 20 insertions(+), 1 deletions(-)\n create mode 100644 git-remote.sh\n\n8810ae2524d3339b8a8341b34b2d3f14ddb9c899\ndiff --git a/Makefile b/Makefile\nindex 37fbe78..58eddd8 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -125,7 +125,7 @@ SCRIPT_SH = \\\n \tgit-applymbox.sh git-applypatch.sh git-am.sh \\\n \tgit-merge.sh git-merge-stupid.sh git-merge-octopus.sh \\\n \tgit-merge-resolve.sh git-merge-ours.sh git-grep.sh \\\n-\tgit-lost-found.sh\n+\tgit-lost-found.sh git-remote.sh\n \n SCRIPT_PERL = \\\n \tgit-archimport.perl git-cvsimport.perl git-relink.perl \\\ndiff --git a/git-remote.sh b/git-remote.sh\nnew file mode 100644\nindex 0000000..04b1ce9\n--- /dev/null\n+++ b/git-remote.sh\n@@ -0,0 +1,19 @@\n+#!/bin/sh\n+\n+USAGE=' [options]'\n+. git-sh-setup\n+. git-parse-remote\n+\n+case \"$#\" in\n+ 0|1) usage ;;\n+esac\n+\n+remote=`get_remote_url \"$1\"` shift;\n+case \"$remote\" in\n+ ssh://*|git+ssh://*|ssh+git://*)\n+ host=`echo \"$remote\" | sed 's!^[^/]*://\\([^/]*\\).*!\\1!'`\n+ path=`echo \"$remote\" | sed 's!^[^/]*://[^/]*\\(.*\\)!\\1!'`\n+ exec ssh -n $host \"GIT_DIR=$path git $@\"\n+ ;;\n+ *) die \"unhandled protocol: $remote\" ;;\n+esac\n-- \n1.3.1\n"},{"id":"19850","messageId":"Pine.LNX.4.63.0605111229510.15923@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4098","inReplyTo":"46a038f90605101713n506207aem1326cd2bf5a1f861@mail.gmail.com","subject":"Re: Implementing branch attributes in git config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-11T10:30:09Z","receivedAt":"2006-05-11T10:30:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 11 May 2006, Martin Langhoff wrote:\n\n> [...] where I now I just mostly copy .git/config around.\n\nWhy not just edit the template?\n\nCiao,\nDscho\n"},{"id":"19851","messageId":"20060511113951.GA28031@coredump.intra.peff.net","threadId":"4098","inReplyTo":"20060511095158.GA23620@coredump.intra.peff.net","subject":"Re: Implementing branch attributes in git config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-05-11T11:39:51Z","receivedAt":"2006-05-11T11:39:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 11, 2006 at 05:51:58AM -0400, Jeff King wrote:\n\n> +remote=`get_remote_url \"$1\"` shift;\n\nOops, this should be:\n remote=`get_remote_url \"$1\"`; shift\nbut it actually works fine under dash (a bug in dash?)\n\n-Peff\n"},{"id":"19852","messageId":"7vejz0wk6k.fsf@assigned-by-dhcp.cox.net","threadId":"4098","inReplyTo":"Pine.LNX.4.64.0605091215340.3718@g5.osdl.org","subject":"Re: Implementing branch attributes in git config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-11T17:22:27Z","receivedAt":"2006-05-11T17:22:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 9 May 2006, Junio C Hamano wrote:\n>> \n>> If we are shooting for \"let's not do this again\", I do not think\n>> (4) without some quoting convention is good enough. Today, we\n>> are talking about branch names so we could give them artificial\n>> limits, which could be weaker than what we already have on the\n>> branch names, but we would later regret that, when we start\n>> wanting to have other names in the configuration (e.g. people's\n>> names).\n>\n> Here's my suggestion as a patch.\n>\n> NOTE! This patch could be applied right now, and to all the branches (to\n> make 1.x, 1.2.x and 1.3.x all support the _syntax_). Even if nothing \n> actually uses it.\n\nLinus,\n\nI've adjusted this patch, your follow-up patch, and Sean's\n\"extended section part is case sensitive\" patch, along with the\ntest tweak to \"maint\" branch. I also prepared them to be\nmergeable to the \"master\" branch. Tentatively it is in \"next\"\nfor testing.\n\nI'm ready to push out \"maint\" (not tagged as 1.3.3 yet) and\n\"next\", but have not done so.\n\nI understand the plan is to have 1.3.3 out from this \"maint\",\nand also merge this in \"master\" about the same time, but I am\nexpecting I will be offline for the rest of the week most of the\ntime, so it would happen over the weekend at the earliest.\n\nDoes that sound good to you?\n\nI do not think we would need v1.1.7 nor v1.2.7 for this. People\nwho have stayed at v1.1.6 or v1.2.6 would need to update if they\nare going to use newer git in their repo anyway, and I do not\nthink of a reason not to update to 1.3.3 but update to 1.1.7 or\n1.2.7 in order to stay at the feature level of 1.1.X or 1.2.X\nseries. We haven't made incompatible changes as far as I\nremember.\n\nHere is what the (adjusted) test case in \"next\" looks like.\nCorresponding one in \"maint\" lack --list so does not have the\nlast hunk. The \"maint\" and \"next\" branches I have locally both\npasses the test.\n\n-- >8 --\n\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex 7090ea9..8260d57 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -229,7 +229,7 @@ test_expect_failure 'invalid key' 'git-r\n test_expect_success 'correct key' 'git-repo-config 123456.a123 987'\n \n test_expect_success 'hierarchical section' \\\n-\t'git-repo-config 1.2.3.alpha beta'\n+\t'git-repo-config Version.1.2.3eX.Alpha beta'\n \n cat > expect << EOF\n [beta] ; silly comment # another comment\n@@ -241,8 +241,8 @@ # empty line\n \tNoNewLine = wow2 for me\n [123456]\n \ta123 = 987\n-[1.2.3]\n-\talpha = beta\n+[Version \"1.2.3eX\"]\n+\tAlpha = beta\n EOF\n \n test_expect_success 'hierarchical section value' 'cmp .git/config expect'\n@@ -251,7 +251,7 @@ cat > expect << EOF\n beta.noindent=sillyValue\n nextsection.nonewline=wow2 for me\n 123456.a123=987\n-1.2.3.alpha=beta\n+version.1.2.3eX.alpha=beta\n EOF\n \n test_expect_success 'working --list' \\\n"}]}