{"thread":{"id":"6376","subject":"Re: [RFC] Git config file reader in Perl (WIP)","startedAt":"2007-01-15T00:44:56Z","lastAt":"2007-01-24T14:14:33Z","messageCount":54,"participants":["Nikolai Weibull","Johannes Schindelin","Eric Wong","Jakub Narebski","Shawn O. Pearce","Junio C Hamano","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31713","messageId":"200701150144.56793.jnareb@gmail.com","threadId":"6376","inReplyTo":null,"subject":"[RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-15T00:44:56Z","receivedAt":"2007-01-15T00:44:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"To make gitweb faster I thought about adding to it, or to Git.pm,\nsimple nonvalidation config file reader. Nonvalidating means that\nit would accept some input which git-repo-config considers invalid.\n\nSome of the trouble is caused because of coner cases like this \nexample\n\n[section \"sub ; # sect \\\" ion\\\\\"] ; \"]\n\tkey = a \" b ; \" ; \" c ; \"\n\nwhich is valid, but strange.\n\nI'm not proficent in Perl, so help is appreciated.\n\n-- >8 --\n#!/usr/bin/perl\n\nuse strict;\nuse warnings;\n\nuse Text::Balanced qw(extract_delimited);\n\n\nsub read_config {\n\tmy $configfile = shift;\n\tmy $section = shift;\n\tmy %config;\n\n\topen my $fd, $configfile\n\t\tor die \"Cannot open $configfile: $!\";\n\n\tmy $sectfull;\n\twhile (my $line = <$fd>) {\n\t\tchomp $line;\n\n\t\tif ($line =~ m/^\\s*\\[\\s*([^][:space:]]*)\\s*\\](.*)$/) {\n\t\t\t# section without subsection\n\n\t\t\tmy $sect = lc($1);\n\n\t\t\t$sectfull = $sect;\n\n\t\t} elsif ($line =~ m/\\s*\\[([^][:space:]]*)\\s\"((?:\\\\.|[^\"])*)\"\\](.*)$/) {\n\t\t\t# section with subsection\n\n\t\t\tmy $sect = lc($1);\n\t\t\tmy $subsect = $2;\n\t\t\t$subsect =~ s/\\\\(.)/$1/g;\n\n\t\t\t$sectfull = \"$sect.$subsect\";\n\n\t\t} elsif ($line =~ m/\\s*(\\w+)\\s*=\\s*(.*?)\\s*$/) {\n\t\t\t# variable assignment\n\n\t\t\tmy $key = lc($1);\n\t\t\tmy $rhs = $2;\n\n\t\t\tmy $value = '';\n\t\t\tmy ($next, $remainder, $prefix) = qw();\n\t\tDELIM: {\n\t\t\t\tdo {\n\t\t\t\t\t($next, $remainder, $prefix) =\n\t\t\t\t\t\textract_delimited($rhs, '\"', qr/(?:\\\\.|[^\"])*/);\n\n\t\t\t\t\tif ($prefix =~ s/\\s*[;#].*$//) {\n\t\t\t\t\t\t# comment in unquoted part\n\t\t\t\t\t\t$value .= $prefix;\n\t\t\t\t\t\tlast DELIM;\n\t\t\t\t\t} else {\n\t\t\t\t\t\t$value .= $prefix if $prefix;\n\t\t\t\t\t\tif ($next && $next =~ s/^\"(.*)\"$/$1/) {\n\t\t\t\t\t\t\t$value .= $next;\n\t\t\t\t\t\t}\n\t\t\t\t\t}\n\n\t\t\t\t\t$rhs = $remainder;\n\t\t\t\t} while ($rhs && $next);\n\t\t\t} # DELIM:\n\n\t\t\tif ($remainder) {\n\t\t\t\t$remainder =~ s/\\s*[;#].*$//;\n\t\t\t\t$value .= $remainder;\n\t\t\t}\n\n\t\t\t$value =~ s/\\\\(.)/$1/g;\n\n\t\t\tif (exists $config{\"$sectfull.$key\"}) {\n\t\t\t\tpush @{$config{\"$sectfull.$key\"}}, $value;\n\t\t\t} else {\n\t\t\t\t$config{\"$sectfull.$key\"} = [ $value ];\n\t\t\t}\n\n\t\t} elsif ($line =~ m/^\\s*(\\w+)\\s*(:?[;#].*)?$/) {\n\t\t\t# boolean variable without value\n\n\t\t\tmy $key = lc($1);\n\n\t\t\tif (exists $config{\"$sectfull.$key\"}) {\n\t\t\t\tpush @{$config{\"$sectfull.$key\"}}, undef;\n\t\t\t} else {\n\t\t\t\t$config{\"$sectfull.$key\"} = [ undef ];\n\t\t\t}\n\t\t} # end if\n\t}\n\n\tclose $fd\n\t\tor die \"Cannot close $configfile: $!\";\n\n\treturn wantarray ? %config : \\%config;\n}\n\n# --------------------------------------------------------------------------\n\nmy %config;\n\n%config = read_config(\"~/git/.git/config\");\n%config = read_config(\"/tmp/jnareb/gitconfig\");\n\nforeach my $ckey (sort keys %config) {\n\tforeach my $cvalue (@{$config{$ckey}}) {\n\t\tif (defined $cvalue) {\n\t\t\tprint \"$ckey=$cvalue\\n\";\n\t\t} else {\n\t\t\tprint \"$ckey\\n\";\n\t\t}\n\t}\n}\n\n__END__\n"},{"id":"31745","messageId":"20070115070826.GB939@localdomain","threadId":"6376","inReplyTo":"200701150144.56793.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-01-15T07:08:26Z","receivedAt":"2007-01-15T07:08:26Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jakub Narebski wrote:\n> To make gitweb faster I thought about adding to it, or to Git.pm,\n> simple nonvalidation config file reader. Nonvalidating means that\n> it would accept some input which git-repo-config considers invalid.\n\nHow about something like git-for-each-ref that dumps the entire output\nof a config file into an eval()-able string? That way we don't have to\ndeal with corner-cases and subtle differences between C and Perl\nimplementations.\n\n-- \nEric Wong\n"},{"id":"31742","messageId":"200701151003.44498.jnareb@gmail.com","threadId":"6376","inReplyTo":"20070115070826.GB939@localdomain","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-15T09:03:43Z","receivedAt":"2007-01-15T09:03:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Eric Wong wrote:\n> Jakub Narebski wrote:\n>> To make gitweb faster I thought about adding to it, or to Git.pm,\n>> simple nonvalidation config file reader. Nonvalidating means that\n>> it would accept some input which git-repo-config considers invalid.\n> \n> How about something like git-for-each-ref that dumps the entire output\n> of a config file into an eval()-able string? That way we don't have to\n> deal with corner-cases and subtle differences between C and Perl\n> implementations.\n\nThe idea is (at least for gitweb) to avoid cost of fork. And I think\nif the format gets documented properly, there should be no differences\nin config file parsing.\n\nPlease remember also that is first draft of git config file reader\nin perl; an alpha version.\n-- \nJakub Narebski\nPoland\n"},{"id":"31693","messageId":"20070115095613.GA4037@localdomain","threadId":"6376","inReplyTo":"200701151003.44498.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-01-15T09:56:14Z","receivedAt":"2007-01-15T09:56:14Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jakub Narebski wrote:\n> Eric Wong wrote:\n> > Jakub Narebski wrote:\n> >> To make gitweb faster I thought about adding to it, or to Git.pm,\n> >> simple nonvalidation config file reader. Nonvalidating means that\n> >> it would accept some input which git-repo-config considers invalid.\n> > \n> > How about something like git-for-each-ref that dumps the entire output\n> > of a config file into an eval()-able string? That way we don't have to\n> > deal with corner-cases and subtle differences between C and Perl\n> > implementations.\n> \n> The idea is (at least for gitweb) to avoid cost of fork. And I think\n> if the format gets documented properly, there should be no differences\n> in config file parsing.\n\nIf the Perl output is redirected to a file (say .git/config.perl) and\nonly regenerated when .git/config changes, `do(\".git/config.perl\")' will\nlikely be faster since all the parsing will be done by Perl itself.\n\n-- \nEric Wong\n"},{"id":"31717","messageId":"20070115100141.GA12257@spearce.org","threadId":"6376","inReplyTo":"20070115095613.GA4037@localdomain","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-15T10:01:41Z","receivedAt":"2007-01-15T10:01:41Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Eric Wong wrote:\n> If the Perl output is redirected to a file (say .git/config.perl) and\n> only regenerated when .git/config changes, `do(\".git/config.perl\")' will\n> likely be faster since all the parsing will be done by Perl itself.\n\nSo long as its automatic in gitweb.cgi and based on the stat\nattributes of .git/config, OK. But my database background tells\nme two copies of the same thing is fishy...\n\n-- \nShawn.\n"},{"id":"31720","messageId":"200701151132.00971.jnareb@gmail.com","threadId":"6376","inReplyTo":"20070115095613.GA4037@localdomain","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-15T10:32:00Z","receivedAt":"2007-01-15T10:32:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Eric Wong wrote:\n> Jakub Narebski wrote:\n>> Eric Wong wrote:\n>>> Jakub Narebski wrote:\n>>>> To make gitweb faster I thought about adding to it, or to Git.pm,\n>>>> simple nonvalidation config file reader. Nonvalidating means that\n>>>> it would accept some input which git-repo-config considers invalid.\n>>> \n>>> How about something like git-for-each-ref that dumps the entire output\n>>> of a config file into an eval()-able string? That way we don't have to\n>>> deal with corner-cases and subtle differences between C and Perl\n>>> implementations.\n>> \n>> The idea is (at least for gitweb) to avoid cost of fork. And I think\n>> if the format gets documented properly, there should be no differences\n>> in config file parsing.\n> \n> If the Perl output is redirected to a file (say .git/config.perl) and\n> only regenerated when .git/config changes, `do(\".git/config.perl\")' will\n> likely be faster since all the parsing will be done by Perl itself.\n\nWould you write \"git repo-config --perl\", then? ;-)\n\nBesides, I'd rather avoid the need for /tmp/gitweb, and I think usually\ngitweb do not have (and should not have) write access to repository.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"31723","messageId":"20070115112635.GA5134@localdomain","threadId":"6376","inReplyTo":"200701151132.00971.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-01-15T11:26:35Z","receivedAt":"2007-01-15T11:26:35Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jakub Narebski wrote:\n> Eric Wong wrote:\n> > Jakub Narebski wrote:\n> >> Eric Wong wrote:\n> >>> Jakub Narebski wrote:\n> >>>> To make gitweb faster I thought about adding to it, or to Git.pm,\n> >>>> simple nonvalidation config file reader. Nonvalidating means that\n> >>>> it would accept some input which git-repo-config considers invalid.\n> >>> \n> >>> How about something like git-for-each-ref that dumps the entire output\n> >>> of a config file into an eval()-able string? That way we don't have to\n> >>> deal with corner-cases and subtle differences between C and Perl\n> >>> implementations.\n> >> \n> >> The idea is (at least for gitweb) to avoid cost of fork. And I think\n> >> if the format gets documented properly, there should be no differences\n> >> in config file parsing.\n> > \n> > If the Perl output is redirected to a file (say .git/config.perl) and\n> > only regenerated when .git/config changes, `do(\".git/config.perl\")' will\n> > likely be faster since all the parsing will be done by Perl itself.\n> \n> Would you write \"git repo-config --perl\", then? ;-)\n\nThe below patch should be a start (only tested on my fairly standard\n.git/config). A --python option should be easy, too :)\n\n> Besides, I'd rather avoid the need for /tmp/gitweb, and I think usually\n> gitweb do not have (and should not have) write access to repository.\n\nGood point. Having to maintain a .git/config.perl in the repository\nwould be a pain from an administrative standpoint; but on the other hand\n.git/config is not often regenerated.\n\nI don't think giving gitweb write access to a repo is a good idea;\neither. Perhaps it would be updated via hook like the HTTP stuff.\nIMHO, there is nothing wrong with gitweb writing to /tmp; however.\n\ndiff --git a/builtin-repo-config.c b/builtin-repo-config.c\nindex 9063311..a9ef358 100644\n--- a/builtin-repo-config.c\n+++ b/builtin-repo-config.c\n@@ -1,5 +1,6 @@\n #include \"builtin.h\"\n #include \"cache.h\"\n+#include \"quote.h\"\n \n static const char git_config_set_usage[] =\n \"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --list\";\n@@ -13,6 +14,7 @@ static int do_all;\n static int do_not_match;\n static int seen;\n static enum { T_RAW, T_INT, T_BOOL } type = T_RAW;\n+static char *last_key;\n \n static int show_all_config(const char *key_, const char *value_)\n {\n@@ -23,6 +25,30 @@ static int show_all_config(const char *key_, const char *value_)\n \treturn 0;\n }\n \n+static int show_perl_config(const char *key_, const char *value_)\n+{\n+\tif (last_key) {\n+\t\tif (strcmp(last_key, key_)) {\n+\t\t\tfree(last_key);\n+\t\t\tlast_key = xstrdup(key_);\n+\t\t\tfputs(\"\\t],\\n\\t\", stdout);\n+\t\t\tperl_quote_print(stdout, key_);\n+\t\t\tfputs(\" => [\\n\", stdout);\n+\t\t}\n+\t} else {\n+\t\tlast_key = xstrdup(key_);\n+\t\tfputc('\\t', stdout);\n+\t\tperl_quote_print(stdout, key_);\n+\t\tfputs(\" => [\\n\", stdout);\n+\t}\n+\tif (value_) {\n+\t\tfputs(\"\\t\\t\", stdout);\n+\t\tperl_quote_print(stdout, value_);\n+\t\tfputs(\",\\n\", stdout);\n+\t}\n+\treturn 0;\n+}\n+\n static int show_config(const char* key_, const char* value_)\n {\n \tchar value[256];\n@@ -138,6 +164,17 @@ int cmd_repo_config(int argc, const char **argv, const char *prefix)\n \t\t\ttype = T_BOOL;\n \t\telse if (!strcmp(argv[1], \"--list\") || !strcmp(argv[1], \"-l\"))\n \t\t\treturn git_config(show_all_config);\n+\t\telse if (!strcmp(argv[1], \"--perl\")) {\n+\t\t\tint rv;\n+\t\t\tputs(\"\\%git_config = (\");\n+\t\t\trv = git_config(show_perl_config);\n+\t\t\tif (last_key) {\n+\t\t\t\tputs(\"\\t]\\n);\\n\");\n+\t\t\t\tfree(last_key);\n+\t\t\t\tlast_key = NULL;\n+\t\t\t}\n+\t\t\treturn rv;\n+\t\t}\n \t\telse if (!strcmp(argv[1], \"--global\")) {\n \t\t\tchar *home = getenv(\"HOME\");\n \t\t\tif (home) {\n\n-- \nEric Wong\n"},{"id":"31722","messageId":"Pine.LNX.4.63.0701151313050.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"20070115112635.GA5134@localdomain","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T12:15:33Z","receivedAt":"2007-01-15T12:15:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Eric Wong wrote:\n\n> > Would you write \"git repo-config --perl\", then? ;-)\n> \n> The below patch should be a start (only tested on my fairly standard \n> .git/config). A --python option should be easy, too :)\n\nA bit shorter (and gets the booleans right, plus being even easier \ntowards --python extension):\n\n---\n\n builtin-repo-config.c | 19 +++++++++++++++++--\n 1 files changed, 17 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-repo-config.c b/builtin-repo-config.c\nindex 9063311..8ebf436 100644\n--- a/builtin-repo-config.c\n+++ b/builtin-repo-config.c\n@@ -1,5 +1,6 @@\n #include \"builtin.h\"\n #include \"cache.h\"\n+#include \"quote.h\"\n \n static const char git_config_set_usage[] =\n \"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --list\";\n@@ -12,11 +13,18 @@ static int use_key_regexp;\n static int do_all;\n static int do_not_match;\n static int seen;\n+static const char *perl_prefix = NULL;\n static enum { T_RAW, T_INT, T_BOOL } type = T_RAW;\n \n static int show_all_config(const char *key_, const char *value_)\n {\n-\tif (value_)\n+\tif (perl_prefix) {\n+\t\tprintf(\"%s\", perl_prefix);\n+\t\tperl_quote_print(stdout, key_);\n+\t\tprintf(\" => \");\n+\t\tperl_quote_print(stdout, value_ ? value_ : \"true\");\n+\t\tperl_prefix = \",\\n\\t\";\n+\t} else if (value_)\n \t\tprintf(\"%s=%s\\n\", key_, value_);\n \telse\n \t\tprintf(\"%s\\n\", key_);\n@@ -138,7 +146,14 @@ int cmd_repo_config(int argc, const char **argv, const char *prefix)\n \t\t\ttype = T_BOOL;\n \t\telse if (!strcmp(argv[1], \"--list\") || !strcmp(argv[1], \"-l\"))\n \t\t\treturn git_config(show_all_config);\n-\t\telse if (!strcmp(argv[1], \"--global\")) {\n+\t\telse if (!strcmp(argv[1], \"--perl\")) {\n+\t\t\tint ret;\n+\t\t\tperl_prefix = \"\\n\\t\";\n+\t\t\tprintf(\"%%git_config = (\");\n+\t\t\tret = git_config(show_all_config);\n+\t\t\tprintf(\"\\n);\\n\");\n+\t\t\treturn ret;\n+\t\t} else if (!strcmp(argv[1], \"--global\")) {\n \t\t\tchar *home = getenv(\"HOME\");\n \t\t\tif (home) {\n \t\t\t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n"},{"id":"31727","messageId":"dbfc82860701150734j7322de15v30dc6822b456ea66@mail.gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701151313050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2007-01-15T15:34:26Z","receivedAt":"2007-01-15T15:34:26Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 1/15/07, Johannes Schindelin wrote:\n\n> On Mon, 15 Jan 2007, Eric Wong wrote:\n\n> > > Would you write \"git repo-config --perl\", then? ;-)\n\n> > The below patch should be a start (only tested on my fairly standard\n> > .git/config). A --python option should be easy, too :)\n\n> A bit shorter (and gets the booleans right, plus being even easier\n> towards --python extension):\n\nIf we're going down this slippery slope, why not just give up and add\na --xml switch instead? Readable by all and a lot more flexible than\n--perl, --python, --ruby, --tcl, --sh, --c++, --fortran, --lisp,\n--html, --that-next-silver-bullet-language-that-hasnt-been-invented-yet-but-will-need-its-own-switch-once-it-has-been.\n\nThat said, parsing the config file as-is can't be so difficult that we\nneed to export it to separate files with a different syntax, now can\nit?\n\n nikolai\n"},{"id":"31687","messageId":"Pine.LNX.4.63.0701151639490.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"dbfc82860701150734j7322de15v30dc6822b456ea66@mail.gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-15T15:44:37Z","receivedAt":"2007-01-15T15:44:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Jan 2007, Nikolai Weibull wrote:\n\n> On 1/15/07, Johannes Schindelin wrote:\n> \n> > On Mon, 15 Jan 2007, Eric Wong wrote:\n> \n> > > > Would you write \"git repo-config --perl\", then? ;-)\n> \n> > > The below patch should be a start (only tested on my fairly standard\n> > > .git/config). A --python option should be easy, too :)\n> \n> > A bit shorter (and gets the booleans right, plus being even easier\n> > towards --python extension):\n> \n> If we're going down this slippery slope, why not just give up and add\n> a --xml switch instead?\n\nAFAIR this switch was meant to _enhance_ performance.\n\n> That said, parsing the config file as-is can't be so difficult that we \n> need to export it to separate files with a different syntax, now can it?\n\nThe point is having one parser to rule them all, and avoid having \ndifferent parsers, all with their own set of shortcomings.\n\nCiao,\nDscho\n"},{"id":"31728","messageId":"200701151700.48159.jnareb@gmail.com","threadId":"6376","inReplyTo":"dbfc82860701150734j7322de15v30dc6822b456ea66@mail.gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-15T16:00:47Z","receivedAt":"2007-01-15T16:00:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nikolai Weibull wrote:\n> On 1/15/07, Johannes Schindelin wrote:\n>> On Mon, 15 Jan 2007, Eric Wong wrote:\n> \n>>>> Would you write \"git repo-config --perl\", then? ;-)\n> \n>>> The below patch should be a start (only tested on my fairly standard\n>>> .git/config). A --python option should be easy, too :)\n> \n>> A bit shorter (and gets the booleans right, plus being even easier\n>> towards --python extension):\n> \n> If we're going down this slippery slope, why not just give up and add\n> a --xml switch instead? Readable by all and a lot more flexible than\n> --perl, --python, --ruby, --tcl, --sh, --c++, --fortran, --lisp,\n> --html, --that-next-silver-bullet-language [...].\n> \n> That said, parsing the config file as-is can't be so difficult that we\n> need to export it to separate files with a different syntax, now can\n> it?\n\nParsing the config file is not _that_ difficult (the first post in this \nthread had config reader in Perl), but it is not that easy: case \n(in)setiviness, quoting, escaping, comments, removing leading and \ntrailing whitespace when not quoted...\n\nP.S. I'd rather have an additional implementation (in Perl) conforming \nto yet to be written git ini-like config file specs, to find places \nwhere canonic parser, git-repo-config, doesn't conform to the specs.\n-- \nJakub Narebski\nPoland\n"},{"id":"31686","messageId":"dbfc82860701150822o47e0e1ecoe22ee81c979dc1ab@mail.gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701151639490.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2007-01-15T16:22:46Z","receivedAt":"2007-01-15T16:22:46Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 1/15/07, Johannes Schindelin wrote:\n\n> On Mon, 15 Jan 2007, Nikolai Weibull wrote:\n\n> > On 1/15/07, Johannes Schindelin wrote:\n\n> > > On Mon, 15 Jan 2007, Eric Wong wrote:\n\n> > > > > Would you write \"git repo-config --perl\", then? ;-)\n\n> > > > The below patch should be a start (only tested on my fairly standard\n> > > > .git/config). A --python option should be easy, too :)\n\n> > > A bit shorter (and gets the booleans right, plus being even easier\n> > > towards --python extension):\n\n> > If we're going down this slippery slope, why not just give up and add\n> > a --xml switch instead?\n\n> AFAIR this switch was meant to _enhance_ performance.\n\nAs far as I can tell, comparing fork() vs. reading a dump with eval\nvs. XML isn't meaningful - parsing a 20-line XML file can hardly be\nmuch more (if it even is more) expensive than evaling a file of the\nsame length.\n\n> > That said, parsing the config file as-is can't be so difficult that we\n> > need to export it to separate files with a different syntax, now can it?\n\n> The point is having one parser to rule them all, and avoid having\n> different parsers, all with their own set of shortcomings.\n\nSo then you must agree that having one export format makes a lot of\nsense, for the same reasons. Not that I think that an export format\nmakes sense in the first place.\n\n nikolai\n"},{"id":"31804","messageId":"20070116095150.GA31467@localdomain","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701151313050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-01-16T09:51:51Z","receivedAt":"2007-01-16T09:51:51Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 15 Jan 2007, Eric Wong wrote:\n> \n> > > Would you write \"git repo-config --perl\", then? ;-)\n> > \n> > The below patch should be a start (only tested on my fairly standard \n> > .git/config). A --python option should be easy, too :)\n> \n> A bit shorter (and gets the booleans right, plus being even easier \n> towards --python extension):\n\nYour version doesn't get arrays right, however.\n\nHere's a Perl/Python/Ruby version below. It should be extendable for\nother languages; feedback and additions appreciated:\n\nNote that usage has been changed to --dump=(perl|python|ruby)\n\nI may add key_suffix to lang_dump just to be consistent with pairings,\nbut array_start seems to handle all cases of it and it would be\nredundant...\n\n--- a/builtin-repo-config.c\n+++ b/builtin-repo-config.c\n@@ -1,5 +1,6 @@\n #include \"builtin.h\"\n #include \"cache.h\"\n+#include \"quote.h\"\n \n static const char git_config_set_usage[] =\n \"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --list\";\n@@ -14,6 +15,90 @@ static int do_not_match;\n static int seen;\n static enum { T_RAW, T_INT, T_BOOL } type = T_RAW;\n \n+struct lang_dump {\n+\tconst char *name;\n+\tconst char *decl_start;\n+\tconst char *decl_end;\n+\tconst char *key_prefix;\n+\tconst char *array_start;\n+\tconst char *array_end;\n+\tconst char *val_prefix;\n+\tconst char *val_suffix;\n+\tconst char *true_val; /* should already be quoted, if needed */\n+\tvoid (*quote_key_fn)(FILE *, const char*);\n+\tvoid (*quote_val_fn)(FILE *, const char*);\n+};\n+static char *last_key;\n+static struct lang_dump *lang;\n+static struct lang_dump lang_dump_defs[] = {\n+\t{ \"perl\",\n+\t\t\"\\%git_config = (\\n\", \");\\n\",\n+\t\t\"\\t\",\n+\t\t\" => [\\n\", \"\\t],\\n\",\n+\t\t\"\\t\\t\", \",\\n\",\n+\t\t\"'true'\",\n+\t\tperl_quote_print, perl_quote_print },\n+\t{ \"python\",\n+\t\t\"git_config = {\\n\", \"}\\n\",\n+\t\t\" \",\n+\t\t\" : [\\n\", \" ],\\n\",\n+\t\t\" \", \",\\n\",\n+\t\t\"True\",\n+\t\tpython_quote_print, python_quote_print },\n+\t{ \"ruby\", /* Ruby is very Perl-like */\n+\t\t\"git_config = {\\n\", \"}\\n\",\n+\t\t\" \",\n+\t\t\" => [\\n\", \" ],\\n\",\n+\t\t\" \", \",\\n\",\n+\t\t\"true\",\n+\t\tperl_quote_print, perl_quote_print },\n+};\n+\n+static int show_lang_config(const char *key_, const char *value_)\n+{\n+\tif (last_key) {\n+\t\tif (strcmp(last_key, key_)) {\n+\t\t\tfree(last_key);\n+\t\t\tfputs(lang->array_end, stdout);\n+\t\t\tgoto new_key;\n+\t\t}\n+\t} else {\n+new_key:\n+\t\tlast_key = xstrdup(key_);\n+\t\tfputs(lang->key_prefix, stdout);\n+\t\tlang->quote_key_fn(stdout, key_);\n+\t\tfputs(lang->array_start, stdout);\n+\t}\n+\tfputs(lang->val_prefix, stdout);\n+\tif (value_)\n+\t\tlang->quote_val_fn(stdout, value_);\n+\telse\n+\t\tfputs(lang->true_val, stdout);\n+\tfputs(lang->val_suffix, stdout);\n+\treturn 0;\n+}\n+\n+static int show_lang_config_all(const char *lang_name)\n+{\n+\tint i, rv;\n+\tfor (i = ARRAY_SIZE(lang_dump_defs); --i >= 0; ) {\n+\t\tif (strcmp(lang_name, lang_dump_defs[i].name))\n+\t\t\tcontinue;\n+\t\tlang = lang_dump_defs + i;\n+\t\tfputs(lang->decl_start, stdout);\n+\t\trv = git_config(show_lang_config);\n+\t\tif (last_key) {\n+\t\t\tfree(last_key);\n+\t\t\tlast_key = NULL;\n+\t\t\tfputs(lang->array_end, stdout);\n+\t\t\tfputs(lang->decl_end, stdout);\n+\t\t}\n+\t\treturn rv;\n+\t}\n+\tfputs(\"Dumping config to '%s' is not yet supported\", stderr);\n+\treturn -1;\n+}\n+\n static int show_all_config(const char *key_, const char *value_)\n {\n \tif (value_)\n@@ -138,6 +223,8 @@ int cmd_repo_config(int argc, const char **argv, const char *prefix)\n \t\t\ttype = T_BOOL;\n \t\telse if (!strcmp(argv[1], \"--list\") || !strcmp(argv[1], \"-l\"))\n \t\t\treturn git_config(show_all_config);\n+\t\telse if (!strncmp(argv[1], \"--dump=\", 7))\n+\t\t\treturn show_lang_config_all(argv[1] + 7);\n \t\telse if (!strcmp(argv[1], \"--global\")) {\n \t\t\tchar *home = getenv(\"HOME\");\n \t\t\tif (home) {\n-- \nEric Wong\n"},{"id":"31806","messageId":"7vwt3nxnak.fsf@assigned-by-dhcp.cox.net","threadId":"6376","inReplyTo":"dbfc82860701150734j7322de15v30dc6822b456ea66@mail.gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-16T10:45:39Z","receivedAt":"2007-01-16T10:45:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Nikolai Weibull\" writes:\n\n> If we're going down this slippery slope, why not just give up and add\n> a --xml switch instead? Readable by all...\n\nPerhaps all except humans.\n\nAt least YAML, please...\n"},{"id":"31807","messageId":"Pine.LNX.4.63.0701161129310.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"20070116095150.GA31467@localdomain","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T10:47:55Z","receivedAt":"2007-01-16T10:47:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Eric Wong wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > On Mon, 15 Jan 2007, Eric Wong wrote:\n> > \n> > > > Would you write \"git repo-config --perl\", then? ;-)\n> > > \n> > > The below patch should be a start (only tested on my fairly standard \n> > > .git/config). A --python option should be easy, too :)\n> > \n> > A bit shorter (and gets the booleans right, plus being even easier \n> > towards --python extension):\n> \n> Your version doesn't get arrays right, however.\n\nThat's right.\n\nI'd like that code to be simpler, though. Way simpler.\n\n> --- a/builtin-repo-config.c\n> +++ b/builtin-repo-config.c\n> @@ -1,5 +1,6 @@\n> #include \"builtin.h\"\n> #include \"cache.h\"\n> +#include \"quote.h\"\n> \n> static const char git_config_set_usage[] =\n> \"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --list\";\n> @@ -14,6 +15,90 @@ static int do_not_match;\n> static int seen;\n> static enum { T_RAW, T_INT, T_BOOL } type = T_RAW;\n> \n> +struct lang_dump {\n> +\tconst char *name;\n> +\tconst char *decl_start;\n> +\tconst char *decl_end;\n> +\tconst char *key_prefix;\n> +\tconst char *array_start;\n> +\tconst char *array_end;\n> +\tconst char *val_prefix;\n> +\tconst char *val_suffix;\n> +\tconst char *true_val; /* should already be quoted, if needed */\n> +\tvoid (*quote_key_fn)(FILE *, const char*);\n> +\tvoid (*quote_val_fn)(FILE *, const char*);\n> +};\n> +static char *last_key;\n> +static struct lang_dump *lang;\n> +static struct lang_dump lang_dump_defs[] = {\n> +\t{ \"perl\",\n> +\t\t\"\\%git_config = (\\n\", \");\\n\",\n0> +\t\t\"\\t\",\n> +\t\t\" => [\\n\", \"\\t],\\n\",\n> +\t\t\"\\t\\t\", \",\\n\",\n> +\t\t\"'true'\",\n> +\t\tperl_quote_print, perl_quote_print },\n\nThe two quote members seem to be the same for _all_ three languages.\n\n> +\t{ \"python\",\n> +\t\t\"git_config = {\\n\", \"}\\n\",\n> +\t\t\" \",\n\nI don't understand why you do not consolidate that into using tabs for \n_all_ backends?\n\n\n> +static int show_lang_config(const char *key_, const char *value_)\n> +{\n> +\tif (last_key) {\n> +\t\tif (strcmp(last_key, key_)) {\n> +\t\t\tfree(last_key);\n> +\t\t\tfputs(lang->array_end, stdout);\n> +\t\t\tgoto new_key;\n> +\t\t}\n> +\t} else {\n> +new_key:\n> +\t\tlast_key = xstrdup(key_);\n> +\t\tfputs(lang->key_prefix, stdout);\n> +\t\tlang->quote_key_fn(stdout, key_);\n> +\t\tfputs(lang->array_start, stdout);\n> +\t}\n\nSo this makes _all_ config vars arrays? It is consistent, yes... but it is \nalso ugly, no?\n\n> +static int show_lang_config_all(const char *lang_name)\n> +{\n> +\tint i, rv;\n> +\tfor (i = ARRAY_SIZE(lang_dump_defs); --i >= 0; ) {\n> +\t\tif (strcmp(lang_name, lang_dump_defs[i].name))\n> +\t\t\tcontinue;\n> +\t\tlang = lang_dump_defs + i;\n\nIMHO this would be much easier to read using a path_list:\n\n\tstruct path_list_item *item = path_list_lookup(lang_name, &langs);\n\n\tif (item == NULL)\n\t\treturn -1;\n\n\tlang = item->util;\n\n> +\t\tfputs(lang->decl_start, stdout);\n> +\t\trv = git_config(show_lang_config);\n> +\t\tif (last_key) {\n> +\t\t\tfree(last_key);\n> +\t\t\tlast_key = NULL;\n> +\t\t\tfputs(lang->array_end, stdout);\n> +\t\t\tfputs(lang->decl_end, stdout);\n\nIf the config is empty, no decl_end is printed, right?\n\n> +\t\t}\n> +\t\treturn rv;\n> +\t}\n> +\tfputs(\"Dumping config to '%s' is not yet supported\", stderr);\n> +\treturn -1;\n> +}\n\nCiao,\nDscho\n"},{"id":"31809","messageId":"Pine.LNX.4.63.0701161206050.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"7vwt3nxnak.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T11:12:45Z","receivedAt":"2007-01-16T11:12:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Junio C Hamano wrote:\n\n> \"Nikolai Weibull\" writes:\n> \n> > If we're going down this slippery slope, why not just give up and add\n> > a --xml switch instead? Readable by all...\n> \n> Perhaps all except humans.\n> \n> At least YAML, please...\n\nI am _strongly_ opposed to all that rubbish. _If_ we want to use \nrepo-config to preformat the config variables, we should either\n\n1) just use \"git repo-config -l\" and STFU, or\n2) introduce something like \"--dump\" which Eric implemented.\n\nEverything else is just _complicating_ matters, and for _what_? _Nothing_ \nat all. If we use repo-config for that task, it should cater for parsing \nby _script languages_, not _users_.\n\nI work with XML everyday. It has its uses. But this here problem is _not_ \none of them. How silly would that be: we parse an easy-to-read format, \nmunge the easy-to-handle internal data format into another \"easy-to-read\" \nformat which is then parsed by a script language into an easy-to-handle \ninternal data format? No. NO.\n\nCiao,\nDscho\n\nP.S.: The more I think about it, we should just use the output of \n\"repo-config -l\".\n"},{"id":"31820","messageId":"200701161514.47908.jnareb@gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701161206050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-16T14:14:47Z","receivedAt":"2007-01-16T14:14:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Tue, 16 Jan 2007, Junio C Hamano wrote:\n> \n>> \"Nikolai Weibull\" writes:\n>> \n>>> If we're going down this slippery slope, why not just give up and add\n>>> a --xml switch instead? Readable by all...\n>> \n>> Perhaps all except humans.\n>> \n>> At least YAML, please...\n> \n> I am _strongly_ opposed to all that rubbish. _If_ we want to use \n> repo-config to preformat the config variables, we should either\n> \n> 1) just use \"git repo-config -l\" and STFU, or\n\n> P.S.: The more I think about it, we should just use the output of \n> \"repo-config -l\".\n\nIt wouldn't work. Subsection and value are (almost) free form, and\nthey can contain '=' in them.\n\nBut I agree that XML is serious overkill...\n\n> 2) introduce something like \"--dump\" which Eric implemented.\n\nIt would be probably best to introduce --dump which would output\nconfig file _as if_ it was written by git-repo-config (probably\nwithout comments).\n\nAll values would be in separate lines, there would be only one\nsection header per each section, values would be quoted if needed\n(if they contain comment delimiter, '=' or whitespace).\n\nE.g.\n\n [section \"subsection\"] key=a \" b; \" c; \" d; \"\n\nwould get rewritten as\n\n [section \"subsection\"]\n \tkey = \"a b; c\"\n\n-- \nJakub Narebski\nPoland\n"},{"id":"31835","messageId":"20070116190900.GA1444@localdomain","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701161206050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-01-16T19:09:00Z","receivedAt":"2007-01-16T19:09:00Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 16 Jan 2007, Junio C Hamano wrote:\n> \n> > \"Nikolai Weibull\" writes:\n> > \n> > > If we're going down this slippery slope, why not just give up and add\n> > > a --xml switch instead? Readable by all...\n> > \n> > Perhaps all except humans.\n> > \n> > At least YAML, please...\n> \n> I am _strongly_ opposed to all that rubbish. _If_ we want to use \n> repo-config to preformat the config variables, we should either\n> \n> 1) just use \"git repo-config -l\" and STFU, or\n> 2) introduce something like \"--dump\" which Eric implemented.\n> \n> Everything else is just _complicating_ matters, and for _what_? _Nothing_ \n> at all. If we use repo-config for that task, it should cater for parsing \n> by _script languages_, not _users_.\n> \n> I work with XML everyday. It has its uses. But this here problem is _not_ \n> one of them. How silly would that be: we parse an easy-to-read format, \n> munge the easy-to-handle internal data format into another \"easy-to-read\" \n> format which is then parsed by a script language into an easy-to-handle \n> internal data format? No. NO.\n\nI agree with these statements. I actually had YAML in my code\noriginally, but ripped it out because it would be another round of\nparsing for any language using a YAML parser.\n\nI like YAML, but no, this isn't the place for it IMHO.\n\n-- \nEric Wong\n"},{"id":"31839","messageId":"20070116195303.GB1444@localdomain","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701161129310.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-01-16T19:53:03Z","receivedAt":"2007-01-16T19:53:03Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> I'd like that code to be simpler, though. Way simpler.\n\nI've tried, but I'm not sure how much farther I can go.\n\n> > +\t{ \"perl\",\n> > +\t\t\"\\%git_config = (\\n\", \");\\n\",\n> 0> +\t\t\"\\t\",\n> > +\t\t\" => [\\n\", \"\\t],\\n\",\n> > +\t\t\"\\t\\t\", \",\\n\",\n> > +\t\t\"'true'\",\n> > +\t\tperl_quote_print, perl_quote_print },\n> \n> The two quote members seem to be the same for _all_ three languages.\n\nYes, I was trying to imagine a corner case where quoting\nfor keys could be different than values.\n\nI know Ruby can use :symbols but those don't support '.' and '-' as\nfar as I know, Perl doesn't require quoting for keys if they match\n^-?\\w+. I guess just using quoted strings as keys is fine enough.\nThe patch below uses the same quote operator for both keys and values.\n\n> > +\t{ \"python\",\n> > +\t\t\"git_config = {\\n\", \"}\\n\",\n> > +\t\t\" \",\n> \n> I don't understand why you do not consolidate that into using tabs for \n> _all_ backends?\n\nI wanted to make things look familiar to people using those languages.\n\nMost Ruby programmers I've seen use 2-space indents. I myself have given\ninto using them when I write Ruby.\n\nPython doesn't seem to care about indentation for data structures, but I\nthink Python programmers prefer spaces for indentation. I'm not very\nexperienced with Python, however.\n\nTabs are my own personal preference for Perl; but indentation is very\ninconsistent in Perl code I've looked at :/. perlstyle(1) actually\nrecommends 4 space indents...\n\nOn the other hand, we are writing for interpreters and not humans. So\nmaybe just using tabs is good enough (some formatting makes debugging\neasier, so I'm not putting everything on one line :).\n\n> > +static int show_lang_config(const char *key_, const char *value_)\n> > +{\n> > +\tif (last_key) {\n> > +\t\tif (strcmp(last_key, key_)) {\n> > +\t\t\tfree(last_key);\n> > +\t\t\tfputs(lang->array_end, stdout);\n> > +\t\t\tgoto new_key;\n> > +\t\t}\n> > +\t} else {\n> > +new_key:\n> > +\t\tlast_key = xstrdup(key_);\n> > +\t\tfputs(lang->key_prefix, stdout);\n> > +\t\tlang->quote_key_fn(stdout, key_);\n> > +\t\tfputs(lang->array_start, stdout);\n> > +\t}\n> \n> So this makes _all_ config vars arrays? It is consistent, yes... but it is \n> also ugly, no?\n\nSomewhat ugly, yes, but I think returning everything as an array would\nmake things easier for code using the data structures. They could\nalways just reference the first element if they didn't want the array\ninstead of having to find the type with ref() or .kind_of?\n\n> > +static int show_lang_config_all(const char *lang_name)\n> > +{\n> > +\tint i, rv;\n> > +\tfor (i = ARRAY_SIZE(lang_dump_defs); --i >= 0; ) {\n> > +\t\tif (strcmp(lang_name, lang_dump_defs[i].name))\n> > +\t\t\tcontinue;\n> > +\t\tlang = lang_dump_defs + i;\n> \n> IMHO this would be much easier to read using a path_list:\n> \n> \tstruct path_list_item *item = path_list_lookup(lang_name, &langs);\n> \n> \tif (item == NULL)\n> \t\treturn -1;\n> \n> \tlang = item->util;\n\nAh, I didn't know about path_list_lookup(). Now that I know about it, I\ndon't think it's worth it to create the extra data structures around\nit. We can just as easily switch to bsearch(3) when we add more\nlanguages.\n\n> > +\t\tfputs(lang->decl_start, stdout);\n> > +\t\trv = git_config(show_lang_config);\n> > +\t\tif (last_key) {\n> > +\t\t\tfree(last_key);\n> > +\t\t\tlast_key = NULL;\n> > +\t\t\tfputs(lang->array_end, stdout);\n> > +\t\t\tfputs(lang->decl_end, stdout);\n> \n> If the config is empty, no decl_end is printed, right?\n\nGood catch. Thanks.\n\n> > +\t\t}\n> > +\t\treturn rv;\n> > +\t}\n> > +\tfputs(\"Dumping config to '%s' is not yet supported\", stderr);\n> > +\treturn -1;\n> > +}\n\n--- a/builtin-repo-config.c\n+++ b/builtin-repo-config.c\n@@ -1,5 +1,6 @@\n #include \"builtin.h\"\n #include \"cache.h\"\n+#include \"quote.h\"\n \n static const char git_config_set_usage[] =\n \"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --list\";\n@@ -14,6 +15,89 @@ static int do_not_match;\n static int seen;\n static enum { T_RAW, T_INT, T_BOOL } type = T_RAW;\n \n+struct lang_dump {\n+\tconst char *name;\n+\tconst char *decl_start;\n+\tconst char *decl_end;\n+\tconst char *key_prefix;\n+\tconst char *array_start;\n+\tconst char *array_end;\n+\tconst char *val_prefix;\n+\tconst char *val_suffix;\n+\tconst char *true_val; /* should already be quoted, if needed */\n+\tvoid (*quote_fn)(FILE *, const char*);\n+};\n+static char *last_key;\n+static struct lang_dump *lang;\n+static struct lang_dump lang_dump_defs[] = {\n+\t{ \"perl\",\n+\t\t\"\\%git_config = (\\n\", \");\\n\",\n+\t\t\"\\t\",\n+\t\t\" => [\\n\", \"\\t],\\n\",\n+\t\t\"\\t\\t\", \",\\n\",\n+\t\t\"'true'\",\n+\t\tperl_quote_print },\n+\t{ \"python\",\n+\t\t\"git_config = {\\n\", \"}\\n\",\n+\t\t\" \",\n+\t\t\" : [\\n\", \" ],\\n\",\n+\t\t\" \", \",\\n\",\n+\t\t\"True\",\n+\t\tpython_quote_print },\n+\t{ \"ruby\", /* Ruby is very Perl-like */\n+\t\t\"git_config = {\\n\", \"}\\n\",\n+\t\t\" \",\n+\t\t\" => [\\n\", \" ],\\n\",\n+\t\t\" \", \",\\n\",\n+\t\t\"true\",\n+\t\tperl_quote_print },\n+};\n+\n+static int show_lang_config(const char *key_, const char *value_)\n+{\n+\tif (last_key) {\n+\t\tif (strcmp(last_key, key_)) {\n+\t\t\tfree(last_key);\n+\t\t\tfputs(lang->array_end, stdout);\n+\t\t\tgoto new_key;\n+\t\t}\n+\t} else {\n+new_key:\n+\t\tlast_key = xstrdup(key_);\n+\t\tfputs(lang->key_prefix, stdout);\n+\t\tlang->quote_fn(stdout, key_);\n+\t\tfputs(lang->array_start, stdout);\n+\t}\n+\tfputs(lang->val_prefix, stdout);\n+\tif (value_)\n+\t\tlang->quote_fn(stdout, value_);\n+\telse\n+\t\tfputs(lang->true_val, stdout);\n+\tfputs(lang->val_suffix, stdout);\n+\treturn 0;\n+}\n+\n+static int show_lang_config_all(const char *lang_name)\n+{\n+\tint i, rv;\n+\tfor (i = ARRAY_SIZE(lang_dump_defs); --i >= 0; ) {\n+\t\tif (strcmp(lang_name, lang_dump_defs[i].name))\n+\t\t\tcontinue;\n+\t\tlang = lang_dump_defs + i;\n+\t\tfputs(lang->decl_start, stdout);\n+\t\trv = git_config(show_lang_config);\n+\t\tif (last_key) {\n+\t\t\tfree(last_key);\n+\t\t\tlast_key = NULL;\n+\t\t\tfputs(lang->array_end, stdout);\n+\t\t}\n+\t\tfputs(lang->decl_end, stdout);\n+\t\treturn rv;\n+\t}\n+\tfputs(\"Dumping config to '%s' is not yet supported\", stderr);\n+\treturn -1;\n+}\n+\n static int show_all_config(const char *key_, const char *value_)\n {\n \tif (value_)\n@@ -138,6 +222,8 @@ int cmd_repo_config(int argc, const char **argv, const char *prefix)\n \t\t\ttype = T_BOOL;\n \t\telse if (!strcmp(argv[1], \"--list\") || !strcmp(argv[1], \"-l\"))\n \t\t\treturn git_config(show_all_config);\n+\t\telse if (!strncmp(argv[1], \"--dump=\", 7))\n+\t\t\treturn show_lang_config_all(argv[1] + 7);\n \t\telse if (!strcmp(argv[1], \"--global\")) {\n \t\t\tchar *home = getenv(\"HOME\");\n \t\t\tif (home) {\n-- \nEric Wong\n"},{"id":"31854","messageId":"dbfc82860701161417r650bc47fva92fa940b4e2cfc0@mail.gmail.com","threadId":"6376","inReplyTo":"200701161514.47908.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2007-01-16T22:17:46Z","receivedAt":"2007-01-16T22:17:46Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 1/16/07, Jakub Narebski wrote:\n> Johannes Schindelin wrote:\n>\n> > On Tue, 16 Jan 2007, Junio C Hamano wrote:\n> >\n> >> \"Nikolai Weibull\" writes:\n> >>\n> >>> If we're going down this slippery slope, why not just give up and add\n> >>> a --xml switch instead? Readable by all...\n> >>\n> >> Perhaps all except humans.\n> >>\n> >> At least YAML, please...\n\n> > P.S.: The more I think about it, we should just use the output of\n> > \"repo-config -l\".\n\n> It wouldn't work. Subsection and value are (almost) free form, and\n> they can contain '=' in them.\n\nSadly, yes. It would be very nice if -l gave unambiguous output for\nall cases, but perhaps -l is more for parsing by people than by seds.\n\n> But I agree that XML is serious overkill...\n\nI don't know if it was clear from my first mail, but I wasn't\nsuggesting --xml as a serious alternative. My point was that if we're\ngoing to go through all the fuss of adding all these switches for\noutputting the configuration file in some fixed format, why not go\nwith one that at least is universal in some sense (not necessarily\nXML). And, as Johannes already pointed out, it's very disturbing\nhaving to dump a configuration file so that it is more easily read by\nother programs. That would suggest that the ini-based format for\ngit's configuration file is suboptimal.\n\nOf course, once git is librified (which is still a long-term goal,\nright?), languages could create bindings to the git library, which\nwould provide access functions to the configuration file. Then we\nwould truly have that one parser to rule them all.\n\n nikolai\n"},{"id":"31856","messageId":"200701162337.32759.jnareb@gmail.com","threadId":"6376","inReplyTo":"dbfc82860701161417r650bc47fva92fa940b4e2cfc0@mail.gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-16T22:37:31Z","receivedAt":"2007-01-16T22:37:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nikolai Weibull wrote:\n> On 1/16/07, Jakub Narebski wrote:\n\n>> But I agree that XML is serious overkill...\n> \n> I don't know if it was clear from my first mail, but I wasn't\n> suggesting --xml as a serious alternative. My point was that if we're\n> going to go through all the fuss of adding all these switches for\n> outputting the configuration file in some fixed format, why not go\n> with one that at least is universal in some sense (not necessarily\n> XML). And, as Johannes already pointed out, it's very disturbing\n> having to dump a configuration file so that it is more easily read by\n> other programs. That would suggest that the ini-based format for\n> git's configuration file is suboptimal.\n\nNo, ini-based, or rather ini-like format for git configuration\nis nice, but I think git is too forgiving in accepting input.\nExamples: section header and key/value pair in the same line,\nallowing multiple quotes in in value part.\n\nWell, the idea I had was to have --dump switch to git-repo-config\nto dump init file as if it was created by git-repo-config invocations,\nwithout any hand editing (canonical format).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"31858","messageId":"Pine.LNX.4.63.0701162337330.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"dbfc82860701161417r650bc47fva92fa940b4e2cfc0@mail.gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T22:42:42Z","receivedAt":"2007-01-16T22:42:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Nikolai Weibull wrote:\n\n> And, as Johannes already pointed out, it's very disturbing having to \n> dump a configuration file so that it is more easily read by other \n> programs.\n\nI never pointed out such a thing. The configuration file is meant to be \nuser-friendly, as the inventor did not mean to have a program like \ngit-repo-config.\n\n> That would suggest that the ini-based format for git's configuration \n> file is suboptimal.\n\nNot at all. Again, git's configuration file is meant for human inspection. \nTherefore, an ini-style file is optimal.\n\nAnd for scripts, we do have git-repo-config. But now some people want to \nbe clever and read the whole config file in, to make it easier to have \ngazillions of configuration options for their script.\n\nI was not happy when we introduced more relaxed section titles, and I am \nnot happy now that I see what problems we introduced with that.\n\n> Of course, once git is librified (which is still a long-term goal,\n> right?), [...]\n\nYou are welcome to contribute to that goal! AFAICT nobody is seriously \nworking on that.\n\nCiao,\nDscho\n"},{"id":"31861","messageId":"Pine.LNX.4.63.0701162352400.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"200701162337.32759.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-16T22:56:13Z","receivedAt":"2007-01-16T22:56:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Jan 2007, Jakub Narebski wrote:\n\n> Nikolai Weibull wrote:\n> > On 1/16/07, Jakub Narebski wrote:\n> \n> >> But I agree that XML is serious overkill...\n> > \n> > I don't know if it was clear from my first mail, but I wasn't\n> > suggesting --xml as a serious alternative. My point was that if we're\n> > going to go through all the fuss of adding all these switches for\n> > outputting the configuration file in some fixed format, why not go\n> > with one that at least is universal in some sense (not necessarily\n> > XML). And, as Johannes already pointed out, it's very disturbing\n> > having to dump a configuration file so that it is more easily read by\n> > other programs. That would suggest that the ini-based format for\n> > git's configuration file is suboptimal.\n> \n> No, ini-based, or rather ini-like format for git configuration\n> is nice,\n\nExactly.\n\n> but I think git is too forgiving in accepting input. Examples: section \n> header and key/value pair in the same line, allowing multiple quotes in \n> in value part.\n\nBut this is nice to the user!\n\n> Well, the idea I had was to have --dump switch to git-repo-config to \n> dump init file as if it was created by git-repo-config invocations, \n> without any hand editing (canonical format).\n\nMy point still stands: if you already parse the user-friendly format, why \nnot dump a parse friendly format? If it weren't for those darn non-alnums \nin the keys, out put of \"git repo-config -l\" would be perfectly \nacceptable.\n\nSo, how about a \"git repo-config --dump\" which outputs a stream of NUL \nseparated keys and values? This should be really easy to \"parse\", and \nthere are no ambiguities: No key or value can contain a NUL.\n\nCiao,\nDscho\n"},{"id":"31864","messageId":"200701170024.10640.jnareb@gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701162352400.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-16T23:24:10Z","receivedAt":"2007-01-16T23:24:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 16. stycznia 2007 23:56, Johannes Schindelin napisał:\n> \n> On Tue, 16 Jan 2007, Jakub Narebski wrote:\n\n>> Well, the idea I had was to have --dump switch to git-repo-config to \n>> dump init file as if it was created by git-repo-config invocations, \n>> without any hand editing (canonical format).\n> \n> My point still stands: if you already parse the user-friendly format, why \n> not dump a parse friendly format? If it weren't for those darn non-alnums \n> in the keys, out put of \"git repo-config -l\" would be perfectly \n> acceptable.\n> \n> So, how about a \"git repo-config --dump\" which outputs a stream of NUL \n> separated keys and values? This should be really easy to \"parse\", and \n> there are no ambiguities: No key or value can contain a NUL.\n\nGood idea, although \"\\n\" would work as well as NUL.\n\nThe only problem is with \"key without value\" case, i.e. something like\n\n [section]\n \tnoval\n\nwhich shows as\n\n section.noval\n\nin \"git repo-config -l\" output (note missing '=' !), and I guess differs\nfor some case from\n\n [section]\n \tnoval = \n\n-- \nJakub Narebski\nPoland\n"},{"id":"31872","messageId":"Pine.LNX.4.63.0701170948420.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"200701170024.10640.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-17T08:51:38Z","receivedAt":"2007-01-17T08:51:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Jan 2007, Jakub Narebski wrote:\n\n> Dnia wtorek 16. stycznia 2007 23:56, Johannes Schindelin napisa?:\n> > \n> > On Tue, 16 Jan 2007, Jakub Narebski wrote:\n> \n> >> Well, the idea I had was to have --dump switch to git-repo-config to \n> >> dump init file as if it was created by git-repo-config invocations, \n> >> without any hand editing (canonical format).\n> > \n> > My point still stands: if you already parse the user-friendly format, why \n> > not dump a parse friendly format? If it weren't for those darn non-alnums \n> > in the keys, out put of \"git repo-config -l\" would be perfectly \n> > acceptable.\n> > \n> > So, how about a \"git repo-config --dump\" which outputs a stream of NUL \n> > separated keys and values? This should be really easy to \"parse\", and \n> > there are no ambiguities: No key or value can contain a NUL.\n> \n> Good idea, although \"\\n\" would work as well as NUL.\n\nNo it would not:\n\n\t[someSection]\n\t\tthisKey = has\\na\\nvalue\\with\\nseveral\\nnewlines\n\n> The only problem is with \"key without value\" case, i.e. something like\n> \n> [section]\n> \tnoval\n> \n> which shows as\n> \n> section.noval\n\nbut is equivalent to\n\n\t[section]\n\t\tnoval = true\n\nSince it is by definition a boolean value.\n\n> in \"git repo-config -l\" output (note missing '=' !), and I guess differs\n> for some case from\n> \n> [section]\n> \tnoval = \n\nYes, this is not a boolean. The difference is that the callback function \nis called with NULL in the former case, and with \"\" in the latter.\n\nHth,\nDscho\n"},{"id":"31874","messageId":"200701171048.03686.jnareb@gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701170948420.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-17T09:48:02Z","receivedAt":"2007-01-17T09:48:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Wed, 17 Jan 2007, Jakub Narebski wrote:\n> \n>> Dnia wtorek 16. stycznia 2007 23:56, Johannes Schindelin napisa?:\n\n>>> So, how about a \"git repo-config --dump\" which outputs a stream of NUL \n>>> separated keys and values? This should be really easy to \"parse\", and \n>>> there are no ambiguities: No key or value can contain a NUL.\n>> \n>> Good idea, although \"\\n\" would work as well as NUL.\n> \n> No it would not:\n> \n> \t[someSection]\n> \t\tthisKey = has\\na\\nvalue\\with\\nseveral\\nnewlines\n\n$ fatal: bad config file line in \n\nThe same with quoted:\n\n \t[someSection]\n \t\tqthisKey = \"has\\na\\nvalue\\with\\nseveral\\nnewlines\"\n\nThere is no escaping besides escaping \" and escape character\ni.e. escaping \\ in git config. Se \"\\n\" would work as well as NUL.\n(It is said explicitely that subsection names cannot contain \"\\n\").\n\n>> The only problem is with \"key without value\" case, i.e. something like\n>> \n>> [section]\n>> \tnoval\n>> \n>> which shows as\n>> \n>> section.noval\n> \n> but is equivalent to\n> \n> \t[section]\n> \t\tnoval = true\n> \n> Since it is by definition a boolean value.\n\nBut only for \"git repo-config --bool --get section.noval\" output.\nSemantically equivalent to \"true\".\n\nBut without --bool it returns like it was \"\".\n\n>> in \"git repo-config -l\" output (note missing '=' !), and I guess differs\n>> for some case from\n>> \n>> [section]\n>> \tnoval = \n> \n> Yes, this is not a boolean. The difference is that the callback function \n> is called with NULL in the former case, and with \"\" in the latter.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"31875","messageId":"Pine.LNX.4.63.0701171138371.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"200701171048.03686.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-17T10:44:04Z","receivedAt":"2007-01-17T10:44:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Jan 2007, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > On Wed, 17 Jan 2007, Jakub Narebski wrote:\n> > \n> >> Dnia wtorek 16. stycznia 2007 23:56, Johannes Schindelin napisa?:\n> \n> >>> So, how about a \"git repo-config --dump\" which outputs a stream of NUL \n> >>> separated keys and values? This should be really easy to \"parse\", and \n> >>> there are no ambiguities: No key or value can contain a NUL.\n> >> \n> >> Good idea, although \"\\n\" would work as well as NUL.\n> > \n> > No it would not:\n> > \n> > \t[someSection]\n> > \t\tthisKey = has\\na\\nvalue\\with\\nseveral\\nnewlines\n> \n> $ fatal: bad config file line in \n\nYeah, sorry. But you got the point.\n\n> The same with quoted:\n> \n> \t[someSection]\n> \t\tqthisKey = \"has\\na\\nvalue\\with\\nseveral\\nnewlines\"\n> \n> There is no escaping besides escaping \" and escape character\n> i.e. escaping \\ in git config. Se \"\\n\" would work as well as NUL.\n> (It is said explicitely that subsection names cannot contain \"\\n\").\n\nSo you want \"git-repo-config --dump\" to output something which has to be \nscanned for escaping sequences?\n\nIf you call\n\n\t$ git repo-config -l\n\nyou will _no longer_ see \"\\n\"s, but rather newlines.\n\nI don't know why you insist on newlines, when a NUL makes perfect sense: \nTake everything until the next NUL. This is the key. Then take everything \nuntil the next NUL. This is the value. Repeat until EOF.\n\n> >> The only problem is with \"key without value\" case, i.e. something like\n> >> \n> >> [section]\n> >> \tnoval\n> >> \n> >> which shows as\n> >> \n> >> section.noval\n> > \n> > but is equivalent to\n> > \n> > \t[section]\n> > \t\tnoval = true\n> > \n> > Since it is by definition a boolean value.\n> \n> But only for \"git repo-config --bool --get section.noval\" output.\n> Semantically equivalent to \"true\".\n> \n> But without --bool it returns like it was \"\".\n\nYes, it returns \"\", but this is _wrong_. A single \"[section] noval\" _only_ \nmakes sense as a boolean. The information lies in its _presence_, which is \nas good as saying \"true\".\n\nCiao,\nDscho\n"},{"id":"31877","messageId":"200701171311.36358.jnareb@gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701171138371.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-17T12:11:35Z","receivedAt":"2007-01-17T12:11:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Wed, 17 Jan 2007, Jakub Narebski wrote:\n> \n>> Johannes Schindelin wrote:\n>>> \n>>> On Wed, 17 Jan 2007, Jakub Narebski wrote:\n>>> \n>>>> Johannes Schindelin wrote:\n>>>> \n>>>>> So, how about a \"git repo-config --dump\" which outputs a stream of NUL \n>>>>> separated keys and values? This should be really easy to \"parse\", and \n>>>>> there are no ambiguities: No key or value can contain a NUL.\n>>>> \n>>>> Good idea, although \"\\n\" would work as well as NUL.\n>>> \n>>> No it would not:\n>>> \n>>> \t[someSection]\n>>> \t\tthisKey = has\\na\\nvalue\\with\\nseveral\\nnewlines\n>> \n>> $ fatal: bad config file line in \n> \n> Yeah, sorry. But you got the point.\n\nNo, I don't got the point. No key or value can contain \"\\n\".\n\n>>>> The only problem is with \"key without value\" case, i.e. something like\n>>>> \n>>>> [section]\n>>>> \tnoval\n>>>> \n>>>> which shows as\n>>>> \n>>>> section.noval\n>>> \n>>> but is equivalent to\n>>> \n>>> \t[section]\n>>> \t\tnoval = true\n>>> \n>>> Since it is by definition a boolean value.\n>> \n>> But only for \"git repo-config --bool --get section.noval\" output.\n>> Semantically equivalent to \"true\".\n>> \n>> But without --bool it returns like it was \"\".\n> \n> Yes, it returns \"\", but this is _wrong_. A single \"[section] noval\" _only_ \n> makes sense as a boolean. The information lies in its _presence_, which is \n> as good as saying \"true\".\n\nWith \"\\n\" as separator you can simply rrturn NUL in the noval case.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"31878","messageId":"Pine.LNX.4.63.0701171334410.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"200701171311.36358.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-17T12:37:59Z","receivedAt":"2007-01-17T12:37:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Jan 2007, Jakub Narebski wrote:\n\n> No key or value can contain \"\\n\".\n\nI just tried this:\n\n\t$ cat > .git/config << EOF\n\t[section] key = \"Hello\\nWorld\"\n\tEOF\n\t$ git-repo-config -l\n\tsection.key=Hello\n\tWorld\n\nSo, values _can_ contain newlines.\n\n> With \"\\n\" as separator you can simply rrturn NUL in the noval case.\n\nWhich would buy you what exactly? You can tell that the user did not say \n\"noval = true\", but \"noval\". Great. But the _effect_ should be the same!\n\nAnyway, I realize you don't like my solution, so I will just shut up.\n\nCiao,\nDscho\n"},{"id":"31885","messageId":"200701171500.33220.jnareb@gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701171334410.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-17T14:00:32Z","receivedAt":"2007-01-17T14:00:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Wed, 17 Jan 2007, Jakub Narebski wrote:\n> \n>> No key or value can contain \"\\n\".\n> \n> I just tried this:\n> \n> \t$ cat > .git/config << EOF\n> \t[section] key = \"Hello\\nWorld\"\n> \tEOF\n> \t$ git-repo-config -l\n> \tsection.key=Hello\n> \tWorld\n> \n> So, values _can_ contain newlines.\n\nSorry, my mistake. I haven't noticed that your previous example\nthe error was \"\\w\", not embedded newlines, and that embedded newlines\nwork.\n \n>> With \"\\n\" as separator you can simply rrturn NUL in the noval case.\n> \n> Which would buy you what exactly? You can tell that the user did not say \n> \"noval = true\", but \"noval\". Great. But the _effect_ should be the same!\n> \n> Anyway, I realize you don't like my solution, so I will just shut up.\n\nI like your solution.\n\nThe only ambiguity is how to deal with '[section] noval' case. You\npropose to treat it as if it was '[section] noval = true' for --dump,\nand not as if it was '[section] noval = ' or '[section] noval = \"\"'.\nGood. But this _has_ to be explained in documentation.\n\nThat said, I still think that having alternate parser for a format\nis a good idea. Otherwise it is not a format, but \"something that\nparser parses\".\n\nBTW. it looks like C escape sequences are parsed, but not octal\nescape sequences, nor no-op escaping other character.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"31905","messageId":"dbfc82860701171008r65006b60vf81df9f82ab25712@mail.gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701162337330.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2007-01-17T18:08:49Z","receivedAt":"2007-01-17T18:08:49Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 1/16/07, Johannes Schindelin wrote:\n\n> On Tue, 16 Jan 2007, Nikolai Weibull wrote:\n>\n> > And, as Johannes already pointed out, it's very disturbing having to\n> > dump a configuration file so that it is more easily read by other\n> > programs.\n>\n> I never pointed out such a thing. The configuration file is meant to be\n> user-friendly, as the inventor did not mean to have a program like\n> git-repo-config.\n\nThen what did you mean in your mail from Jan 16, 2007 12:12 PM:\n\n How silly would that be: we parse an easy-to-read format,\n munge the easy-to-handle internal data format into another \"easy-to-read\"\n format which is then parsed by a script language into an easy-to-handle\n internal data format? No. NO.\n\n?\n\n> > That would suggest that the ini-based format for git's configuration\n> > file is suboptimal.\n\n> Not at all. Again, git's configuration file is meant for human inspection.\n> Therefore, an ini-style file is optimal.\n\nIt is suboptimal because it's hard for computers to inspect. An\noptimal format would be accessible by all, whether human, machine,\nrobot, android, what have you.\n\nI really don't like that people take my statements and somehow contort\nthem into meaning something else. You can't take my statement and\nthen claim that because git's configuration file was meant for human\ninspection my /suggestion/ about it being suboptimal is somehow flawed\nbecause I didn't consider the original intent of the file in question.\n\nAgreed, ini-style files are sweet for humans, but that's not what I\nwas saying. My claim was that ini-style files aren't necessarily\noptimal for parsing by computers. I think that was made clear. Also,\nI only /suggested/ that it may be /suboptimal/ not that it in fact\n/is/ suboptimal.\n\n> And for scripts, we do have git-repo-config. But now some people want to\n> be clever and read the whole config file in, to make it easier to have\n> gazillions of configuration options for their script.\n\nI maintain the git completion-definition for Zsh. Being able to get\nat the configuration settings is important, both for the completion of\ngit-repo-config, but also to provide completions of remote\nrepositories. 'git-repo-config -l' works fine, but it's not\nguaranteed to be unambiguous, as the name of a remote repository can\ncontain characters like '=', so it can be difficult to decide where to\nsplit the name of the remote repository from the url it represents as\nthe url can also contain '='.\n\n> I was not happy when we introduced more relaxed section titles, and I am\n> not happy now that I see what problems we introduced with that.\n\nI'm with you on this one.\n\n nikolai\n"},{"id":"31909","messageId":"200701172022.52015.jnareb@gmail.com","threadId":"6376","inReplyTo":"dbfc82860701171008r65006b60vf81df9f82ab25712@mail.gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-17T19:22:51Z","receivedAt":"2007-01-17T19:22:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nikolai Weibull wrote:\n\n> I maintain the git completion-definition for Zsh.\n\nCould you add it to contrib/completion/ or at least put link\nin http://git.or.cz/gitwiki/InterfacesFrontendsAndTools ?\n\nTIA\n-- \nJakub Narebski\nPoland\n"},{"id":"31910","messageId":"200701172025.14870.jnareb@gmail.com","threadId":"6376","inReplyTo":"dbfc82860701171008r65006b60vf81df9f82ab25712@mail.gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-17T19:25:14Z","receivedAt":"2007-01-17T19:25:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nikolai Weibull wrote:\n> On 1/16/07, Johannes Schindelin wrote:\n\n>> I was not happy when we introduced more relaxed section titles, and I am\n>> not happy now that I see what problems we introduced with that.\n> \n> I'm with you on this one.\n\nMore relaxed section (actually _sub_section) titles are not the problem.\nThe fact that they are case sensitive (where section and key names\nare not) can be.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"31916","messageId":"dbfc82860701171201k3131e42flf03b129e39167c9c@mail.gmail.com","threadId":"6376","inReplyTo":"200701172022.52015.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2007-01-17T20:01:45Z","receivedAt":"2007-01-17T20:01:45Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 1/17/07, Jakub Narebski wrote:\n> Nikolai Weibull wrote:\n>\n> > I maintain the git completion-definition for Zsh.\n>\n> Could you add it to contrib/completion/ or at least put link\n> in http://git.or.cz/gitwiki/InterfacesFrontendsAndTools ?\n\nI did announce it way back when, but since it's included with new\nreleases of Zsh there's really nothing interesting to add or link to.\nIt's also in Zsh's CVS repository, but I do my updates here:\n\n http://git.bitwi.se/?p=dot-home.git;a=tree\n\nalthough I now realize that I haven't pushed some recent updates to\nthat repository yet.\n\n nikolai\n"},{"id":"31933","messageId":"Pine.LNX.4.63.0701180146060.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"dbfc82860701171008r65006b60vf81df9f82ab25712@mail.gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T00:50:45Z","receivedAt":"2007-01-18T00:50:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Jan 2007, Nikolai Weibull wrote:\n\n> On 1/16/07, Johannes Schindelin wrote:\n> \n> > On Tue, 16 Jan 2007, Nikolai Weibull wrote:\n> > \n> > > And, as Johannes already pointed out, it's very disturbing having to\n> > > dump a configuration file so that it is more easily read by other\n> > > programs.\n> > \n> > I never pointed out such a thing. The configuration file is meant to be\n> > user-friendly, as the inventor did not mean to have a program like\n> > git-repo-config.\n> \n> Then what did you mean in your mail from Jan 16, 2007 12:12 PM:\n> \n> How silly would that be: we parse an easy-to-read format,\n> munge the easy-to-handle internal data format into another \"easy-to-read\"\n> format which is then parsed by a script language into an easy-to-handle\n> internal data format? No. NO.\n> \n> ?\n\nIt was about the human-readable -> internal -> human-readable -> internal\nchain. Those are way too many transformations for little gain.\n\nIMHO modern programs spend 99% of the time are spent transforming data. \nMost of them is unnecessary. That's bad.\n\n> > > That would suggest that the ini-based format for git's configuration\n> > > file is suboptimal.\n> \n> > Not at all. Again, git's configuration file is meant for human inspection.\n> > Therefore, an ini-style file is optimal.\n> \n> It is suboptimal because it's hard for computers to inspect. An\n> optimal format would be accessible by all, whether human, machine,\n> robot, android, what have you.\n\nThere's a reason we program in C, Java, etc. and not in Assembler. \nSometimes computers and humans are too different to be able to cater for \nboth of them at the same time.\n\nI know, I know. The geek inside me disagrees, too. But my experience \ndoesn't.\n\nCiao,\nDscho\n"},{"id":"32056","messageId":"200701191310.32417.jnareb@gmail.com","threadId":"6376","inReplyTo":"200701171500.33220.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-19T12:10:31Z","receivedAt":"2007-01-19T12:10:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> BTW. it looks like C escape sequences are parsed, but not octal\n> escape sequences, nor no-op escaping other character.\n \nFrom a bit of testing, as documentation of config file format\nis woefully incomplete, (yes, I know I should use the source)\n_some_ of C escape sequences aka. character escape codes (CEC)\nare parsed:\n - \"\\t\", tab character (HT, TAB)\n - \"\\n\", newline (NL)\n - \"\\b\", backspace (BS)\nIt's a bit strange that \"\\b\" is parsed...\n\nOther CEC cause \"fatal: bad config file line 41 in \"\nerror:\n - \"\\r\", return (CR)\n - \"\\f\", form feed (FF)\n - \"\\a\", alarm (bell) (BEL)\n - \"\\e\", escape (ESC)\n - \"\\v\", vertical tab (VT)\nI think supporting \"\\e\" could be useful, but also dangerous.\n\nOctal char sequences (like \\040 or \\0 for NUL) are not supported\nand result in \"bad config file\" error.\n\nLiteral/unknown escape sequences like \"\\w\" or \"\\.\" also result\nin \"bad config file\" error, with the obvious exception of escaping\nquote character i.e. \\\" and escaping escape character i.e. \\\\\n\nValues of configuration variables can span multiple lines by escaping\nnewline, i.e. putting \\ as the last character. Nice. (This doesn't work\nfor comments, of course). This doesn't work for section headers nor key \nnames.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"32058","messageId":"200701191325.06337.jnareb@gmail.com","threadId":"6376","inReplyTo":"200701191310.32417.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-19T12:25:05Z","receivedAt":"2007-01-19T12:25:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n> Jakub Narebski wrote:\n> \n>> BTW. it looks like C escape sequences are parsed, but not octal\n>> escape sequences, nor no-op escaping other character.\n> \n> From a bit of testing, as documentation of config file format\n> is woefully incomplete, (yes, I know I should use the source)\n> _some_ of C escape sequences aka. character escape codes (CEC)\n> are parsed:\n> - \"\\t\", tab character (HT, TAB)\n> - \"\\n\", newline (NL)\n> - \"\\b\", backspace (BS)\n> It's a bit strange that \"\\b\" is parsed...\n[...]\n> Values of configuration variables can span multiple lines by escaping\n> newline, i.e. putting \\ as the last character. Nice.\n\n>From config.c:parse_value:73\n\n\t\tif (c == '\\\\') {\n\t\t\tc = get_next_char();\n\t\t\tswitch (c) {\n\t\t\tcase '\\n':\n\t\t\t\tcontinue;\n\t\t\tcase 't':\n\t\t\t\tc = '\\t';\n\t\t\t\tbreak;\n\t\t\tcase 'b':\n\t\t\t\tc = '\\b';\n\t\t\t\tbreak;\n\t\t\tcase 'n':\n\t\t\t\tc = '\\n';\n\t\t\t\tbreak;\n\t\t\t/* Some characters escape as themselves */\n\t\t\tcase '\\\\': case '\"':\n\t\t\t\tbreak;\n\t\t\t/* Reject unknown escape sequences */\n\t\t\tdefault:\n\t\t\t\treturn NULL;\n\t\t\t}\n\n-- \nJakub Narebski\nPoland\n"},{"id":"32063","messageId":"Pine.LNX.4.63.0701191420000.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"200701191310.32417.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-19T13:20:40Z","receivedAt":"2007-01-19T13:20:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Jan 2007, Jakub Narebski wrote:\n\n> From a bit of testing, as documentation of config file format is \n> woefully incomplete, (yes, I know I should use the source) _some_ of C \n> escape sequences aka. character escape codes (CEC) are parsed:\n\nNo, you should not just use the source. You should use the source _and_ \ncomplete the documentation.\n\nCiao,\nDscho\n"},{"id":"32096","messageId":"200701192344.11972.jnareb@gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701191420000.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-19T22:44:11Z","receivedAt":"2007-01-19T22:44:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Fri, 19 Jan 2007, Jakub Narebski wrote:\n> \n>> From a bit of testing, as documentation of config file format is \n>> woefully incomplete, (yes, I know I should use the source) _some_ of C \n>> escape sequences aka. character escape codes (CEC) are parsed:\n> \n> No, you should not just use the source. You should use the source _and_ \n> complete the documentation.\n\nSomething like the patch below? Untested! (\"make doc\" up to \ngit-repo-config.txt compiles, though).\n\nI'm not sure how to tell that you can have [section] if you have\n[section \"subsection\"], but you don't need to. And I probably forgot\nto add some information.\n\nAnd I'm not sure if some behavior should not be changed, for example\nallowing _any_ line to be continued with `\\`, or that other character\nescape sequences and perhaps also octal character sequences should be\nallowed (either that or `\\b` should not be parsed).\n\nI can send proper patch if requested, but I'd rather above issues\nwere resolved first.\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex da7fde5..9544308 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -14,14 +14,53 @@ dot-separated segment and the section name is everything before the last\n dot. The variable names are case-insensitive and only alphanumeric\n characters are allowed. Some variables may appear multiple times.\n \n+Syntax\n+~~~~~~\n+\n The syntax is fairly flexible and permissive; whitespaces are mostly\n-ignored. The '#' and ';' characters begin comments to the end of line,\n-blank lines are ignored, lines containing strings enclosed in square\n-brackets start sections and all the other lines are recognized\n-as setting variables, in the form 'name = value'. If there is no equal\n-sign on the line, the entire line is taken as 'name' and the variable\n-is recognized as boolean \"true\". String values may be entirely or partially\n-enclosed in double quotes; some variables may require special value format.\n+ignored. The '#' and ';' characters begin comments to the end of line,\n+blank lines are ignored.\n+\n+The file consists of sections and variables. A section begins with\n+the name of the section in square brackets and continues until the next\n+section begins. Section names are not case sensitive. Each variable\n+must belong to some section, which means that there must be section\n+header before first setting of a variable.\n+\n+Sections can be further divided into subsections. To begin a subsection\n+put it name in double quotes, separated by space from the section name,\n+in the section header, like in example below\n+\n+\t[section \"subsection\"]\n+\n+Subsection names can contain whitespace and are case sensitive. Variables\n+may belong directly to a section, or to a given subsection.\n+\n+All the other lines are recognized as setting variables, in the form\n+'name = value'. If there is no equal sign on the line, the entire line\n+is taken as 'name' and the variable is recognized as boolean \"true\".\n+Variable names are case insensitive. There can be more than one value\n+for a given variable; we say then that variable is multivalued.\n+\n+Leading and trailing whitespace in a variable value is discarded.\n+Internal whitespace within a variable value is retained verbatim.\n+\n+String values may be entirely or partially enclosed in double quotes.\n+You need to enclose variable value in double quotes if you want to\n+preserve leading or trailing whitespace, or if variable value contains\n+beginning of comment characters, it means if it contains `#` or `;`.\n+Double quote `\"` and backslash `\\` characters in variable value must\n+be escaped: use `\\\"` for `\"`, and `\\\\` for `\\`.\n+\n+The following escape sequences (beside `\\\"` and `\\\\`) are recognized:\n+`\\n` for newline character (NL), `\\t` for horizontal tabulation (HT, TAB)\n+and `\\b` for backspace (BS). No other character escape codes, nor octal\n+char sequences are valid.\n+\n+Variable value ending in a `\\` is continued on the next line in the \n+customary UNIX fashion.\n+\n+Some variables may require special value format.\n \n Example\n ~~~~~~~\n"},{"id":"32107","messageId":"Pine.LNX.4.63.0701200100530.12889@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"200701192344.11972.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-20T00:08:14Z","receivedAt":"2007-01-20T00:08:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Jan 2007, Jakub Narebski wrote:\n\n> +Sections can be further divided into subsections. To begin a subsection\n> +put it name in double quotes, separated by space from the section name,\n\n ^ \"its\"\n\n> +in the section header, like in example below\n> +\n> +\t[section \"subsection\"]\n\nI wonder if we should also mention the (case insensitive) alternative \n\"[section.subsection]\", to give a better idea to people why we actually \ncheck for \"section.subsection\" in the code.\n\n> +All the other lines are recognized as setting variables, in the form\n> +'name = value'. If there is no equal sign on the line, the entire line\n> +is taken as 'name' and the variable is recognized as boolean \"true\".\n> +Variable names are case insensitive.\n\nThey cannot contain anything else than alphanumeric characters, in \nparticular no whitespace.\n\n>\t\t\t\t\t There can be more than one value\n> +for a given variable; we say then that variable is multivalued.\n\nMaybe give the example of \"remote..fetch\" to explain why? Or maybe \nnot.\n\n> +The following escape sequences (beside `\\\"` and `\\\\`) are recognized:\n> +`\\n` for newline character (NL), `\\t` for horizontal tabulation (HT, TAB)\n> +and `\\b` for backspace (BS). No other character escape codes, nor octal\n> +char sequences are valid.\n\nI did not even know about BS! Does it make sense to allow it, really?\n\n> +Some variables may require special value format.\n\nI think you can safely skip that; it should be evident that the format of \nthe variables depends on the purpose.\n\nCiao,\nDscho\n"},{"id":"32109","messageId":"7v8xfyczxi.fsf@assigned-by-dhcp.cox.net","threadId":"6376","inReplyTo":"200701192344.11972.jnareb@gmail.com","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-20T00:19:37Z","receivedAt":"2007-01-20T00:19:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> I'm not sure how to tell that you can have [section] if you have\n> [section \"subsection\"], but you don't need to.\n\ns/I'm not .*that//; would be enough, I think.\n\n> And I'm not sure if some behavior should not be changed, for example\n> allowing _any_ line to be continued with `\\`, or that other character\n> escape sequences and perhaps also octal character sequences should be\n> allowed (either that or `\\b` should not be parsed).\n\nI do not think we need continuation line for [] headers, if that\nis what you mean. I offhand do not think anybody would scream\nif we start parsing full c-quote.\n\nOne thing that left me puzzled after reading the description was\nwhat a user can do with \"subsection\". It is unclear from the\ndescription if [section \"sub.section\"], [section\"sub.sec=ti.on\"]\nor worse yet, [section \"sub\\nsection with an embbedded LF\"] are\nallowed. The rest seemed sane.\n\nI think the current repo-config handles sane cases alright, but\nit is still fragile in error cases. For example:\n\n\t$ git repo-config 'foo.bar=bzz\n baz.boo' foobar\n\ndoes not currently barf, but results in a corrupted config file.\n\n\t$ git repo-config 'foo.bar=bzz\n baz.boo'\n\tfatal: bad config file line 56 in .git/config\n\n $ sed -ne '55,$p' .git/config\n [foo \"bar=bzz\n baz\"]\n boo = foobar\n\nThe only way we use the subsection names for (almost arbitrary)\nend user string is to store branch names, so LF is not an issue\nand we could forbid it (if need arises loosening the restriction\nwhile updating the code to behave sanely is easier than leaving\nit open without properly checking).\n"},{"id":"32118","messageId":"200701200159.15355.jnareb@gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701200100530.12889@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Git config file reader in Perl (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-20T00:59:14Z","receivedAt":"2007-01-20T00:59:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Fri, 19 Jan 2007, Jakub Narebski wrote: \n\n>> +in the section header, like in example below\n>> +\n>> +\t[section \"subsection\"]\n> \n> I wonder if we should also mention the (case insensitive) alternative \n> \"[section.subsection]\", to give a better idea to people why we actually \n> check for \"section.subsection\" in the code.\n\nI'm not sure. \"section.subsection\" can be treated as section with that\nname, strange because it has '.' in it, and not subsection \"subsection\"\nof section \"section\". git-repo-config writes section with subsection\nin above format.\n \n>> +All the other lines are recognized as setting variables, in the form\n>> +'name = value'. If there is no equal sign on the line, the entire line\n>> +is taken as 'name' and the variable is recognized as boolean \"true\".\n>> +Variable names are case insensitive.\n> \n> They cannot contain anything else than alphanumeric characters, in \n> particular no whitespace.\n\nContrary to for example also ini-like smb.conf:\n Leading, trailing and _internal_ whitespace in section and parameter\n names is irrelevant.\n\n>>\t\t\t\t\t There can be more than one value\n>> +for a given variable; we say then that variable is multivalued.\n> \n> Maybe give the example of \"remote..fetch\" to explain why? Or maybe \n> not.\n\nI put it because in this git config differs from standard ini-format.\n\n>> +The following escape sequences (beside `\\\"` and `\\\\`) are recognized:\n>> +`\\n` for newline character (NL), `\\t` for horizontal tabulation (HT, TAB)\n>> +and `\\b` for backspace (BS). No other character escape codes, nor octal\n>> +char sequences are valid.\n> \n> I did not even know about BS! Does it make sense to allow it, really?\n\nThat is the question I'm also asking...\n\n>> +Some variables may require special value format.\n> \n> I think you can safely skip that; it should be evident that the format of \n> the variables depends on the purpose.\n\nThis was in the original, and I think it is better left (at least for now).\n\nI wonder if to write about --bool and --int formats...\n-- \nJakub Narebski\nPoland\n"},{"id":"32125","messageId":"Pine.LNX.4.63.0701200224180.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"7v8xfyczxi.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-20T01:25:37Z","receivedAt":"2007-01-20T01:25:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nThis will no longer work:\n\n$ git repo-config 'key.with\nnewline' some-value\n\nSigned-off-by: Johannes Schindelin \n---\n\tOn Fri, 19 Jan 2007, Junio C Hamano wrote:\n\t\n\t> I think the current repo-config handles sane cases alright, but\n\t> it is still fragile in error cases. For example:\n\t> \n\t> \t$ git repo-config 'foo.bar=bzz\n\t> baz.boo' foobar\n\t> \n\t> does not currently barf, but results in a corrupted config file.\n\n\tNow it barfs.\n\n config.c | 5 +++++\n t/t1300-repo-config.sh | 6 ++++++\n 2 files changed, 11 insertions(+), 0 deletions(-)\n\ndiff --git a/config.c b/config.c\nindex b6082f5..c08c668 100644\n--- a/config.c\n+++ b/config.c\n@@ -661,6 +661,11 @@ int git_config_set_multivar(const char* key, const char* value,\n \t\t\t\tgoto out_free;\n \t\t\t}\n \t\t\tc = tolower(c);\n+\t\t} else if (c == '\\n') {\n+\t\t\tfprintf(stderr, \"invalid key (newline): %s\\n\", key);\n+\t\t\tfree(store.key);\n+\t\t\tret = 1;\n+\t\t\tgoto out_free;\n \t\t}\n \t\tstore.key[i] = c;\n \t}\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex 60acdd3..eb7455b 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -418,5 +418,11 @@ EOF\n \n test_expect_success 'quoting' 'cmp .git/config expect'\n \n+test_expect_failure 'key with newline' 'git repo-config key.with\\\\\\\n+newline 123'\n+\n+test_expect_success 'value with newline' 'git repo-config key.sub value.with\\\\\\\n+newline'\n+\n test_done\n \n-- \n1.5.0.rc1.g5a400-dirty\n"},{"id":"32128","messageId":"7vzm8ea32b.fsf@assigned-by-dhcp.cox.net","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701200224180.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-20T01:40:12Z","receivedAt":"2007-01-20T01:40:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks.\n"},{"id":"32154","messageId":"11693017892595-git-send-email-jnareb@gmail.com","threadId":"6376","inReplyTo":"7v8xfyczxi.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Documentation/config.txt: Document config file syntax better","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-20T14:03:09Z","receivedAt":"2007-01-20T14:03:09Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Separate part of Documentation/config.txt which deals with git config file\nsyntax into \"Syntax\" subsection, and expand it. Add information about\nsubsections, boolean values, escaping and escape sequences in string\nvalues, and continuing variable value on the next line.\n\nAdd also proxy settings to config file example to show example of\npartially enclosed in double quotes string value.\n\nParts based on comments by Junio C Hamano, Johannes Schindelin,\nand the smb.conf(5) man page.\n\nSigned-off-by: Jakub Narebski \n---\nOn Sat, 20 Jan 2007, Johannes Schindelin wrote:\n> On Fri, 19 Jan 2007, Jakub Narebski wrote:\n\n>> +in the section header, like in example below\n>> +\n>> +\t[section \"subsection\"]\n> \n> I wonder if we should also mention the (case insensitive) alternative \n> \"[section.subsection]\", to give a better idea to people why we actually \n> check for \"section.subsection\" in the code.\n\nAdded one line note about this.\n\n>> +All the other lines are recognized as setting variables, in the form\n>> +'name = value'. If there is no equal sign on the line, the entire line\n>> +is taken as 'name' and the variable is recognized as boolean \"true\".\n>> +Variable names are case insensitive.\n> \n> They cannot contain anything else than alphanumeric characters, in \n> particular no whitespace.\n\nIt is mentioned above \"Syntax\" section, but perhaps it should be repeated.\nI haven't took a look at code to check what values for section names and\nfor key/variable names are allowed.\n\n>> +Some variables may require special value format.\n> \n> I think you can safely skip that; it should be evident that the format of \n> the variables depends on the purpose.\n\nThis was in the original, and I think it is better left (at least for now).\n\n\nJunio C Hamano wrote:\n> Jakub Narebski writes:\n> \n>> I'm not sure how to tell that you can have [section] if you have\n>> [section \"subsection\"], but you don't need to.\n> \n> s/I'm not .*that//; would be enough, I think.\n\nThanks for suggestion. I have used it (although perhaps the preceding\nsentence is now not needed).\n\n> One thing that left me puzzled after reading the description was\n> what a user can do with \"subsection\". It is unclear from the\n> description if [section \"sub.section\"], [section \"sub.sec=ti.on\"]\n> or worse yet, [section \"sub\\nsection with an embbedded LF\"] are\n> allowed. The rest seemed sane.\n\nI'm not sure what is allowed in section name, and in subsection name,\nso for now I have left it as is. I can amend this commit, or add new\ncommit explaining this.\n\n\nBTW. currently one of examples from git-repo-config(1) doesn't work:\n\n To add a new proxy, without altering any of the existing ones, use\n \n ------------\n % git repo-config core.gitproxy '\"proxy\" for example.com'\n ------------\n\nI think it would be better instead of adding quotes if needed, just\ndo _not_ escape quotes. But that leaves the problem what to do if one\nputs value with trailing or leading whitespace, or comment character\noutside quotes using git-repo-config...\n\n\n Documentation/config.txt | 69 +++++++++++++++++++++++++++++++++++++++++----\n 1 files changed, 62 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex da7fde5..03133e2 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -14,14 +14,65 @@ dot-separated segment and the section name is everything before the last\n dot. The variable names are case-insensitive and only alphanumeric\n characters are allowed. Some variables may appear multiple times.\n \n+Syntax\n+~~~~~~\n+\n The syntax is fairly flexible and permissive; whitespaces are mostly\n-ignored. The '#' and ';' characters begin comments to the end of line,\n-blank lines are ignored, lines containing strings enclosed in square\n-brackets start sections and all the other lines are recognized\n-as setting variables, in the form 'name = value'. If there is no equal\n-sign on the line, the entire line is taken as 'name' and the variable\n-is recognized as boolean \"true\". String values may be entirely or partially\n-enclosed in double quotes; some variables may require special value format.\n+ignored. The '#' and ';' characters begin comments to the end of line,\n+blank lines are ignored.\n+\n+The file consists of sections and variables. A section begins with\n+the name of the section in square brackets and continues until the next\n+section begins. Section names are not case sensitive. Each variable\n+must belong to some section, which means that there must be section\n+header before first setting of a variable.\n+\n+Sections can be further divided into subsections. To begin a subsection\n+put its name in double quotes, separated by space from the section name,\n+in the section header, like in example below:\n+\n+--------\n+\t[section \"subsection\"]\n+\n+--------\n+\n+Subsection names can contain whitespace and are case sensitive. Variables\n+may belong directly to a section, or to a given subsection. You can have\n+`[section]` if you have `[section \"subsection\"]`, but you don't need to.\n+\n+There is also (case insensitive) alternative `[section.subsection]` syntax.\n+\n+All the other lines are recognized as setting variables, in the form\n+'name = value'. If there is no equal sign on the line, the entire line\n+is taken as 'name' and the variable is recognized as boolean \"true\".\n+Variable names are case insensitive. There can be more than one value\n+for a given variable; we say then that variable is multivalued.\n+\n+Leading and trailing whitespace in a variable value is discarded.\n+Internal whitespace within a variable value is retained verbatim.\n+\n+The values following the equals sign in variable assign are all either\n+a string, an integer, or a boolean. Boolean values may be given as yes/no,\n+0/1 or true/false. Case is not significant in boolean values, when\n+converting value to the canonical form using '--bool' type specifier;\n+git-repo-config will ensure that the output is \"true\" or \"false\".\n+\n+String values may be entirely or partially enclosed in double quotes.\n+You need to enclose variable value in double quotes if you want to\n+preserve leading or trailing whitespace, or if variable value contains\n+beginning of comment characters (if it contains '#' or ';').\n+Double quote '`\"`' and backslash '`\\`' characters in variable value must\n+be escaped: use '`\\\"`' for '`\"`' and '`\\\\`' for '`\\`'.\n+\n+The following escape sequences (beside '`\\\"`' and '`\\\\`') are recognized:\n+'`\\n`' for newline character (NL), '`\\t`' for horizontal tabulation (HT, TAB)\n+and '`\\b`' for backspace (BS). No other char escape sequence, nor octal\n+char sequences are valid.\n+\n+Variable value ending in a '`\\`' is continued on the next line in the\n+customary UNIX fashion.\n+\n+Some variables may require special value format.\n \n Example\n ~~~~~~~\n@@ -40,6 +91,10 @@ Example\n \t\tremote = origin\n \t\tmerge = refs/heads/devel\n \n+\t# Proxy settings\n+\t[core]\n+\t\tgitProxy=\"ssh\" for \"ssh://kernel.org/\"\n+\t\tgitProxy=default-proxy ; for the rest\n \n Variables\n ~~~~~~~~~\n-- \n1.4.4.3\n"},{"id":"32297","messageId":"81b0412b0701220706w65ed0657h1d69819e7879ed40@mail.gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701200224180.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-22T15:06:50Z","receivedAt":"2007-01-22T15:06:50Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/20/07, Johannes Schindelin wrote:\n> --- a/config.c\n> +++ b/config.c\n> @@ -661,6 +661,11 @@ int git_config_set_multivar(const char* key, const char* value,\n> goto out_free;\n> }\n> c = tolower(c);\n> + } else if (c == '\\n') {\n> + fprintf(stderr, \"invalid key (newline): %s\\n\", key);\n\nBTW, why config.c never uses error() or warn()?\n"},{"id":"32298","messageId":"Pine.LNX.4.63.0701221619110.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"81b0412b0701220706w65ed0657h1d69819e7879ed40@mail.gmail.com","subject":"Re: [PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-22T15:21:26Z","receivedAt":"2007-01-22T15:21:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Jan 2007, Alex Riesen wrote:\n\n> On 1/20/07, Johannes Schindelin wrote:\n> > --- a/config.c\n> > +++ b/config.c\n> > @@ -661,6 +661,11 @@ int git_config_set_multivar(const char* key, const\n> > char* value,\n> > goto out_free;\n> > }\n> > c = tolower(c);\n> > + } else if (c == '\\n') {\n> > + fprintf(stderr, \"invalid key (newline): %s\\n\", key);\n> \n> BTW, why config.c never uses error() or warn()?\n\nMainly because error() was meant to be used as \"return error(\"blabla\");\", \nand we tried to discern different failures by different return values.\n\nBut yeah, I think it would be acceptable to use error() instead of \nfprintf() even then.\n\nBTW IMHO we will probably never libify git; too many too complicated cases \nexist already.\n\nCiao,\nDscho\n"},{"id":"32299","messageId":"11694795473648-git-send-email-jnareb@gmail.com","threadId":"6376","inReplyTo":"11693017892595-git-send-email-jnareb@gmail.com","subject":"[PATCH] Documentation/config.txt: Document config file syntax better","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-22T15:25:47Z","receivedAt":"2007-01-22T15:25:47Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Separate part of Documentation/config.txt which deals with git config file\nsyntax into \"Syntax\" subsection, and expand it. Add information about\nsubsections, boolean values, escaping and escape sequences in string\nvalues, and continuing variable value on the next line.\n\nAdd also proxy settings to config file example to show example of\npartially enclosed in double quotes string value.\n\nParts based on comments by Junio C Hamano, Johannes Schindelin,\nconfig.c, and the smb.conf(5) man page.\n\nSigned-off-by: Jakub Narebski \n---\nJunio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> What about my Documentation/config.txt changes?\n> \n> I was not sure about that one, given a lot of commentary in your\n> message, suggesting more research and revision is needed, like\n> these...\n> \n>>>> +All the other lines are recognized as setting variables, in the form\n>>>> +'name = value'. If there is no equal sign on the line, the entire line\n>>>> +is taken as 'name' and the variable is recognized as boolean \"true\".\n>>>> +Variable names are case insensitive.\n>>> \n>>> They cannot contain anything else than alphanumeric characters, in \n>>> particular no whitespace.\n>>\n>> It is mentioned above \"Syntax\" section, but perhaps it should be repeated.\n>> I haven't took a look at code to check what values for section names and\n>> for key/variable names are allowed.\n>> ...\n>>> One thing that left me puzzled after reading the description was\n>>> what a user can do with \"subsection\". It is unclear from the\n>>> description if [section \"sub.section\"], [section \"sub.sec=ti.on\"]\n>>> or worse yet, [section \"sub\\nsection with an embbedded LF\"] are\n>>> allowed. The rest seemed sane.\n>>\n>> I'm not sure what is allowed in section name, and in subsection name,\n>> so for now I have left it as is. I can amend this commit, or add new\n>> commit explaining this.\n\nI hope that this is satisfactory.\n\n\nI haven't wrote about current limits on the lengths: 256/2 for section\nplus subsection name length, 256 for fully qualified variable name,\n1024 for value length; I think this does not belong to end user\ndocumentation.\n\n Documentation/config.txt | 76 +++++++++++++++++++++++++++++++++++++++++----\n 1 files changed, 69 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex f1f409d..77a2b16 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -14,14 +14,72 @@ dot-separated segment and the section name is everything before the last\n dot. The variable names are case-insensitive and only alphanumeric\n characters are allowed. Some variables may appear multiple times.\n \n+Syntax\n+~~~~~~\n+\n The syntax is fairly flexible and permissive; whitespaces are mostly\n-ignored. The '#' and ';' characters begin comments to the end of line,\n-blank lines are ignored, lines containing strings enclosed in square\n-brackets start sections and all the other lines are recognized\n-as setting variables, in the form 'name = value'. If there is no equal\n-sign on the line, the entire line is taken as 'name' and the variable\n-is recognized as boolean \"true\". String values may be entirely or partially\n-enclosed in double quotes; some variables may require special value format.\n+ignored. The '#' and ';' characters begin comments to the end of line,\n+blank lines are ignored.\n+\n+The file consists of sections and variables. A section begins with\n+the name of the section in square brackets and continues until the next\n+section begins. Section names are not case sensitive. Only alphanumeric\n+characters, '`-`' and '`.`' are allowed in section names. Each variable\n+must belong to some section, which means that there must be section\n+header before first setting of a variable.\n+\n+Sections can be further divided into subsections. To begin a subsection\n+put its name in double quotes, separated by space from the section name,\n+in the section header, like in example below:\n+\n+--------\n+\t[section \"subsection\"]\n+\n+--------\n+\n+Subsection names can contain any characters (doublequote '`\"`', backslash\n+'`\\`' and newline have to be entered escaped as '`\\\"`', '`\\\\`' and '`\\n`',\n+respecitvely) and are case sensitive. Section header cannot span multiple\n+lines. Variables may belong directly to a section or to a given subsection.\n+You can have `[section]` if you have `[section \"subsection\"]`, but you\n+don't need to.\n+\n+There is also (case insensitive) alternative `[section.subsection]` syntax.\n+In this syntax subsection names follow the same restrictions as for section\n+name.\n+\n+All the other lines are recognized as setting variables, in the form\n+'name = value'. If there is no equal sign on the line, the entire line\n+is taken as 'name' and the variable is recognized as boolean \"true\".\n+The variable names are case-insensitive and only alphanumeric\n+characters and '`-`' are allowed. There can be more than one value\n+for a given variable; we say then that variable is multivalued.\n+\n+Leading and trailing whitespace in a variable value is discarded.\n+Internal whitespace within a variable value is retained verbatim.\n+\n+The values following the equals sign in variable assign are all either\n+a string, an integer, or a boolean. Boolean values may be given as yes/no,\n+0/1 or true/false. Case is not significant in boolean values, when\n+converting value to the canonical form using '--bool' type specifier;\n+`git-repo-config` will ensure that the output is \"true\" or \"false\".\n+\n+String values may be entirely or partially enclosed in double quotes.\n+You need to enclose variable value in double quotes if you want to\n+preserve leading or trailing whitespace, or if variable value contains\n+beginning of comment characters (if it contains '#' or ';').\n+Double quote '`\"`' and backslash '`\\`' characters in variable value must\n+be escaped: use '`\\\"`' for '`\"`' and '`\\\\`' for '`\\`'.\n+\n+The following escape sequences (beside '`\\\"`' and '`\\\\`') are recognized:\n+'`\\n`' for newline character (NL), '`\\t`' for horizontal tabulation (HT, TAB)\n+and '`\\b`' for backspace (BS). No other char escape sequence, nor octal\n+char sequences are valid.\n+\n+Variable value ending in a '`\\`' is continued on the next line in the\n+customary UNIX fashion.\n+\n+Some variables may require special value format.\n \n Example\n ~~~~~~~\n@@ -40,6 +98,10 @@ Example\n \t\tremote = origin\n \t\tmerge = refs/heads/devel\n \n+\t# Proxy settings\n+\t[core]\n+\t\tgitProxy=\"ssh\" for \"ssh://kernel.org/\"\n+\t\tgitProxy=default-proxy ; for the rest\n \n Variables\n ~~~~~~~~~\n-- \n1.4.4.4\n"},{"id":"32300","messageId":"81b0412b0701220733j1002bd9dse8db491512c7a500@mail.gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701221619110.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-22T15:33:48Z","receivedAt":"2007-01-22T15:33:48Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/22/07, Johannes Schindelin wrote:\n> BTW IMHO we will probably never libify git; too many too complicated cases\n> exist already.\n\nWe probably don't need it libified completely. Just reading and writing of\nthe object database and tags/references and very simple revision walking\nwill be a very good start and possibly enough for anything which _uses_ the\ndatabase, like importers and exporters.from other VCS or just programs which\nneed a versioned storage. Comparing, archeology and maintenance tasks are\nmore often done manually and can wait (they do now, don't they?) until the\nrest of diff, patch and revision walking machinery libified properly.\n"},{"id":"32302","messageId":"Pine.LNX.4.63.0701221643030.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"81b0412b0701220733j1002bd9dse8db491512c7a500@mail.gmail.com","subject":"Re: [PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-22T15:44:46Z","receivedAt":"2007-01-22T15:44:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Jan 2007, Alex Riesen wrote:\n\n> On 1/22/07, Johannes Schindelin wrote:\n> > BTW IMHO we will probably never libify git; too many too complicated cases\n> > exist already.\n> \n> We probably don't need it libified completely. Just reading and writing of\n> the object database and tags/references and very simple revision walking\n> will be a very good start [...]\n\n... and even these use xmalloc(), which die()s on out-of-memory. Note that \nit would be a really horrible work to libify that, since you basically \nhave to insert gazillions of free() calls at the right point, which we \ndon't have to, since exit() cleans up after us anyway.\n\nCiao,\nDscho\n"},{"id":"32304","messageId":"81b0412b0701220809w1851cbfp5aa7e027ce79eed3@mail.gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701221643030.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-22T16:09:13Z","receivedAt":"2007-01-22T16:09:13Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/22/07, Johannes Schindelin wrote:\n> > > BTW IMHO we will probably never libify git; too many too complicated cases\n> > > exist already.\n> >\n> > We probably don't need it libified completely. Just reading and writing of\n> > the object database and tags/references and very simple revision walking\n> > will be a very good start [...]\n>\n> ... and even these use xmalloc(), which die()s on out-of-memory. Note that\n> it would be a really horrible work to libify that, since you basically\n> have to insert gazillions of free() calls at the right point, which we\n> don't have to, since exit() cleans up after us anyway.\n\nDidn't say it'd be simple. Just not impossible.\n"},{"id":"32383","messageId":"Pine.LNX.4.63.0701231225450.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6376","inReplyTo":"81b0412b0701220809w1851cbfp5aa7e027ce79eed3@mail.gmail.com","subject":"Re: [PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T11:26:14Z","receivedAt":"2007-01-23T11:26:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Jan 2007, Alex Riesen wrote:\n\n> On 1/22/07, Johannes Schindelin wrote:\n> > > > BTW IMHO we will probably never libify git; too many too \n> > > > complicated cases exist already.\n> > >\n> > > We probably don't need it libified completely. Just reading and writing of\n> > > the object database and tags/references and very simple revision walking\n> > > will be a very good start [...]\n> > \n> > ... and even these use xmalloc(), which die()s on out-of-memory. Note that\n> > it would be a really horrible work to libify that, since you basically\n> > have to insert gazillions of free() calls at the right point, which we\n> > don't have to, since exit() cleans up after us anyway.\n> \n> Didn't say it'd be simple. Just not impossible.\n\nI thought that was what you meant by \"very simple revision walking\".\n\nCiao,\nDscho\n"},{"id":"32388","messageId":"81b0412b0701230447sb3cb3e6y125be4d4fa8952f2@mail.gmail.com","threadId":"6376","inReplyTo":"Pine.LNX.4.63.0701231225450.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] config_set_multivar(): disallow newlines in keys","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-23T12:47:58Z","receivedAt":"2007-01-23T12:47:58Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/23/07, Johannes Schindelin wrote:\n> > > > We probably don't need it libified completely. Just reading and writing of\n> > > > the object database and tags/references and very simple revision walking\n> > > > will be a very good start [...]\n> > >\n> > > ... and even these use xmalloc(), which die()s on out-of-memory. Note that\n> > > it would be a really horrible work to libify that, since you basically\n> > > have to insert gazillions of free() calls at the right point, which we\n> > > don't have to, since exit() cleans up after us anyway.\n> >\n> > Didn't say it'd be simple. Just not impossible.\n>\n> I thought that was what you meant by \"very simple revision walking\".\n>\n\nthat'd be \"just a part of revision walking\". Dunno what part yet,\nbecause I still have to come up with convincing example of where\nonly a libgit could be used: just committers and history browsers\nshould not have any problems just using plumbing (no, stupid\nmicrosoft's createprocess is not a reason enough).\n"},{"id":"32522","messageId":"11696480732656-git-send-email-jnareb@gmail.com","threadId":"6376","inReplyTo":"11694795473648-git-send-email-jnareb@gmail.com","subject":"[PATCH 2/1] Documentation/config.txt: Correct info about subsection name","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-24T14:14:33Z","receivedAt":"2007-01-24T14:14:33Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Contrary to variable values, in subsection names parsing character\nescape codes (besides literal escaping of \" as \\\", and \\ as \\\\)\nis not performed; subsection name cannot contain newlines.\n\nSigned-off-by: Jakub Narebski \n---\n Documentation/config.txt | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 77a2b16..d8244b1 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -37,8 +37,8 @@ in the section header, like in example below:\n \n --------\n \n-Subsection names can contain any characters (doublequote '`\"`', backslash\n-'`\\`' and newline have to be entered escaped as '`\\\"`', '`\\\\`' and '`\\n`',\n+Subsection names can contain any characters except newline (doublequote\n+'`\"`' and backslash have to be escaped as '`\\\"`' and '`\\\\`',\n respecitvely) and are case sensitive. Section header cannot span multiple\n lines. Variables may belong directly to a section or to a given subsection.\n You can have `[section]` if you have `[section \"subsection\"]`, but you\n-- \n1.4.4.4\n"}]}