{"thread":{"id":"34661","subject":"Re: git should not use a default user.email config value","startedAt":"2013-08-09T19:42:14Z","lastAt":"2013-08-14T15:41:08Z","messageCount":46,"participants":["Jonathan Nieder","Thorsten Glaser","Felipe Contreras","Jeff King","Junio C Hamano","Michael Haggerty","Andreas Schwab","Aaron Schrab","Andrew Ardill","Greg Troxel","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"224937","messageId":"20130809194214.GV14690@google.com","threadId":"34661","inReplyTo":"20130809134236.28143.75775.reportbug@tglase.lan.tarent.de","subject":"Re: git should not use a default user.email config value","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-08-09T19:42:14Z","receivedAt":"2013-08-09T19:42:14Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Thorsten,\n\nThorsten Glaser wrote[1]:\n\n> git config user.email SHOULD NOT default to $(id -un)@$(hostname -f)\n> because just too many cow-orkers seem to be unable to follow basic\n> instructions\n\nHeh.\n\nCan you say a little more about your setup? In a university\nenvironment with sysadmin-managed email and /etc/mailname set up\ncorrectly it is handy that people can start working without doing\nanything special to configure git's \"[user] email\" setting. On the\nother hand it is obnoxious to receive patches with wrong authorship\ninformation. So I'm wondering if there's some detail that\ndistinguishes between these cases.\n\nIncidentally, it's been a long time since I looked at the \"Please\nconfigure your email address; I've made something up, but you'll want\nto check it\" message:\n\n\tYour name and email address were configured automatically based\n\ton your username and hostname. Please check that they are accurate.\n\tYou can suppress this message by setting them explicitly:\n\n\t git config --global user.name \"Your Name\"\n\t git config --global user.email you@example.com\n\n\tAfter doing this, you may fix the identity used for this commit with:\n\n\t git commit --amend --reset-author\n\nI wonder if it's too gentle and long to get the point across. Would\nsomething the following (including the guesses in the message for\neasier copy-pasting) help?\n\n\tNo name and email address configured, so I had to guess. You\n\tcan suppress this message by setting your identity explicitly:\n\n\t\tgit config --global user.name \"Thorsten Glaser\"\n\t\tgit config --global user.email tg@mirbsd.de\n\n\tAfter doing so, you may fix the identity used for this commit\n\twith \"git commit --amend --reset-author\".\n\nIt may also make sense to distinguish between cases where a mailname\nis set and not set. Git already notices the cases where the guessed\nemail address ends with \".(none)\" and errors out, and it could make\nsense to be more aggressive.\n\nHope that helps,\nJonathan\n\n[1] http://bugs.debian.org/719226\n"},{"id":"224945","messageId":"Pine.BSM.4.64L.1308091956060.28970@herc.mirbsd.org","threadId":"34661","inReplyTo":"20130809194214.GV14690@google.com","subject":"Re: git should not use a default user.email config value","fromName":"Thorsten Glaser","fromEmail":"tg@mirbsd.de","sentAt":"2013-08-09T20:00:49Z","receivedAt":"2013-08-09T20:00:49Z","isPatch":false,"sender":{"key":"tg@mirbsd.de","avatar":"https://gravatar.com/avatar/e4bb7217fcb56def9c570cc3803933454cebf7617d95e8fa82d3b56141c53413?d=mp&s=160"},"body":"Jonathan Nieder dixit:\n\n>Can you say a little more about your setup? In a university\n>environment with sysadmin-managed email and /etc/mailname set up\n>correctly it is handy that people can start working without doing\n\nAh okay. We don’t have /etc/mailname set up I think and,\nadditionally, the Unix user name doesn’t match the eMail\nlocalpart, so that won’t work anyway.\n\nThough we’re having a very heterogenous desktop environment\nnowadays so I can’t really know all specifics.\n\nAt least, I think, most devs seem to use the Unix git client\nnow, whereas for svn they use the one that comes with Eclipse…\n\n>I wonder if it's too gentle and long to get the point across. Would\n>something the following (including the guesses in the message for\n>easier copy-pasting) help?\n\nDefinitely not. It needs to fail hard if user.email is not set,\ni.e. refuse to accept the commit.\n\n>is set and not set. Git already notices the cases where the guessed\n>email address ends with \".(none)\" and errors out, and it could make\n>sense to be more aggressive.\n\nThe guessed addresses are like 'denge@pc-bn-041.lan.tarent.de'\ninstead of 'd.enge@tarent.de' which is the correct Kolab address\n(this information can be publicly accessed since the project I\nnoticed it in is on our public FusionForge instance, so I don’t\nthink sharing specifics is bad here, but please don’t hammer our\npoor trainee with spam now). So they’re a “correct” unix username\nat a correct FQDN (which, thanks to split-horizon, even would\nwork internally, except there’s of course no MTA set up) and\nwon’t be caught by *.(none) matches.\n\nHope this helps.\n\nThanks,\n//mirabilos\n-- \ntarent solutions GmbH\nRochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/\nTel: +49 228 54881-393 • Fax: +49 228 54881-314\nHRB AG Bonn 5168 • USt-ID (VAT): DE122264941\nGeschäftsführer: Boris Esser, Sebastian Mancke\n"},{"id":"224949","messageId":"CAMP44s1SxSd-cM_P-JL2+skB6mDmar_QwFv9mYp5BrXUKTz61w@mail.gmail.com","threadId":"34661","inReplyTo":"Pine.BSM.4.64L.1308091956060.28970@herc.mirbsd.org","subject":"Re: git should not use a default user.email config value","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-09T20:30:17Z","receivedAt":"2013-08-09T20:30:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Aug 9, 2013 at 3:00 PM, Thorsten Glaser wrote:\n> Jonathan Nieder dixit:\n\n>>I wonder if it's too gentle and long to get the point across. Would\n>>something the following (including the guesses in the message for\n>>easier copy-pasting) help?\n>\n> Definitely not. It needs to fail hard if user.email is not set,\n> i.e. refuse to accept the commit.\n\nCompletely agree, and I argued this point some time ago.\n\n>>is set and not set. Git already notices the cases where the guessed\n>>email address ends with \".(none)\" and errors out, and it could make\n>>sense to be more aggressive.\n>\n> The guessed addresses are like 'denge@pc-bn-041.lan.tarent.de'\n> instead of 'd.enge@tarent.de' which is the correct Kolab address\n> (this information can be publicly accessed since the project I\n> noticed it in is on our public FusionForge instance, so I don’t\n> think sharing specifics is bad here, but please don’t hammer our\n> poor trainee with spam now). So they’re a “correct” unix username\n> at a correct FQDN (which, thanks to split-horizon, even would\n> work internally, except there’s of course no MTA set up) and\n> won’t be caught by *.(none) matches.\n\nThis is how to implement that:\n\nFrom f1feaa05ce3772d8006078c4aeabcbd55b52d58e Mon Sep 17 00:00:00 2001\nFrom: Felipe Contreras 2nd \nDate: Tue, 13 Nov 2012 07:33:12 +0100\nSubject: [PATCH] ident: don't allow implicit email addresses\n\nSigned-off-by: Felipe Contreras \n---\n ident.c | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/ident.c b/ident.c\nindex 1c123e6..85fc729 100644\n--- a/ident.c\n+++ b/ident.c\n@@ -301,9 +301,9 @@ const char *fmt_ident(const char *name, const char *email,\n \t}\n\n \tif (strict && email == git_default_email.buf &&\n-\t strstr(email, \"(none)\")) {\n+\t\t!(user_ident_explicitly_given & IDENT_MAIL_GIVEN)) {\n \t\tfputs(env_hint, stderr);\n-\t\tdie(\"unable to auto-detect email address (got '%s')\", email);\n+\t\tdie(\"no explicit email address\");\n \t}\n\n \tif (want_date) {\n-- \n1.8.3.267.gbb4989f\n\n\n-- \nFelipe Contreras\n"},{"id":"224969","messageId":"20130809223758.GB7160@sigill.intra.peff.net","threadId":"34661","inReplyTo":"20130809194214.GV14690@google.com","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-09T22:37:58Z","receivedAt":"2013-08-09T22:37:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 09, 2013 at 12:42:14PM -0700, Jonathan Nieder wrote:\n\n> I wonder if it's too gentle and long to get the point across. Would\n> something the following (including the guesses in the message for\n> easier copy-pasting) help?\n> \n> \tNo name and email address configured, so I had to guess. You\n> \tcan suppress this message by setting your identity explicitly:\n> \n> \t\tgit config --global user.name \"Thorsten Glaser\"\n> \t\tgit config --global user.email tg@mirbsd.de\n> \n> \tAfter doing so, you may fix the identity used for this commit\n> \twith \"git commit --amend --reset-author\".\n\nI don't know if including the name and email helps that much. It should\nalready be printed along with that message, like:\n\n $ git commit --allow-empty -m foo\n [master ba77f94] foo\n Committer: Jeff King \n Your name and email address were configured automatically based\n on your username and hostname. Please check that they are accurate.\n You can suppress this message by setting them explicitly:\n\n git config --global user.name \"Your Name\"\n git config --global user.email you@example.com\n\n After doing this, you may fix the identity used for this commit with:\n\n git commit --amend --reset-author\n\n> It may also make sense to distinguish between cases where a mailname\n> is set and not set. Git already notices the cases where the guessed\n> email address ends with \".(none)\" and errors out, and it could make\n> sense to be more aggressive.\n\nYeah, there are basically three levels of ident:\n\n 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.\n\n 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn\n but use it.\n\n 3. It looks obviously bogus (e.g., we do not have a domain name).\n Reject it.\n\nWe can move some cases from (2) down to (3), like when we use\ngethostname rather than /etc/mailname. But we risk breaking people's\nexisting setups. I don't think we know how many people rely on the\nimplicit hostname selection and would be affected. I don't know if there\nis a good way to find out short of changing it and seeing who screams.\nWe can put a deprecation warning in the release notes, but people tend\nto ignore those. Or perhaps now that we have had the long obnoxious\nimplicit-ident warning for several versions, everybody has finally set\nuser.email and the time is right to change.\n\nAnother option could to add an option to control the strictness. We\nusually have a chicken-and-egg problem here with individual installs\n(i.e., any person who could set \"user.trustHostname = false\" could just\nas easily have set \"user.email\"). But in an institutional setting, the\nadmin could set such a config in /etc/gitconfig for everybody. Or for a\nsystem like Debian, the packager could include the option, knowing that\nany reasonably configured system should have /etc/mailname set up (which\nis not something we can necessarily count on for other operating\nsystems).\n\n-Peff\n"},{"id":"224973","messageId":"7v38qi4g7r.fsf@alter.siamese.dyndns.org","threadId":"34661","inReplyTo":"20130809223758.GB7160@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-09T23:06:16Z","receivedAt":"2013-08-09T23:06:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yeah, there are basically three levels of ident:\n>\n> 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.\n>\n> 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn\n> but use it.\n>\n> 3. It looks obviously bogus (e.g., we do not have a domain name).\n> Reject it.\n>\n> We can move some cases from (2) down to (3), like ...\n\nJudging from Thorsten's earlier response, I am afraid no amount of\nautodetection would help the users of that site. If we were to do\nsomething, /etc/gitconfig as you outlined below would be the way to\ngo, even though it makes me feel dirty.\n\n> Another option could to add an option to control the strictness. We\n> usually have a chicken-and-egg problem here with individual installs\n> (i.e., any person who could set \"user.trustHostname = false\" could just\n> as easily have set \"user.email\"). But in an institutional setting, the\n> admin could set such a config in /etc/gitconfig for everybody. Or for a\n> system like Debian, the packager could include the option, knowing that\n> any reasonably configured system should have /etc/mailname set up (which\n> is not something we can necessarily count on for other operating\n> systems).\n>\n> -Peff\n"},{"id":"224975","messageId":"20130809231928.GY14690@google.com","threadId":"34661","inReplyTo":"20130809223758.GB7160@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-08-09T23:19:28Z","receivedAt":"2013-08-09T23:19:28Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> Yeah, there are basically three levels of ident:\n>\n> 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.\n>\n> 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn\n> but use it.\n>\n> 3. It looks obviously bogus (e.g., we do not have a domain name).\n> Reject it.\n>\n> We can move some cases from (2) down to (3), like when we use\n> gethostname rather than /etc/mailname. But we risk breaking people's\n> existing setups. I don't think we know how many people rely on the\n> implicit hostname selection and would be affected. I don't know if there\n> is a good way to find out short of changing it and seeing who screams.\n\nYes. The result from a reverse DNS lookup is almost never the right\nmailname.\n\n * Small installations tend to use a smarthost.\n * Large installations tend to use more than one machine, and only\n one machine's name gets the MX record.\n \nSo except for cases where someone doesn't actually care about the\nrecorded author and just has a script making commits (such users\nalready suffer from the \".(none)\" heuristic), I don't think this would\nhurt anyone.\n\n> We can put a deprecation warning in the release notes, but people tend\n> to ignore those.\n\nNot so much a deprecation warning as an \"Here is one of the more\nnoticeable changes in this release\" announcement.\n\nI'm pretty sure a deprecation warning would not help here. Either\npeople are affected and we say \"WARNING: You were doing something\nperfectly reasonable, but now we discourage it\", or, more likely,\npeople are not affected. Announcing a change too loudly to users not\naffected by it has a very bad side effect of training them not to pay\nmuch attention to release notes.\n\n[...]\n> Another option could to add an option to control the strictness.\n\nI suspect a new config item for this is a bad idea, given how simple\nit is to choose a good default for everyone.\n\nThanks,\nJonathan\n"},{"id":"224987","messageId":"20130810061720.GA30185@sigill.intra.peff.net","threadId":"34661","inReplyTo":"7v38qi4g7r.fsf@alter.siamese.dyndns.org","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-10T06:17:20Z","receivedAt":"2013-08-10T06:17:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 09, 2013 at 04:06:16PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Yeah, there are basically three levels of ident:\n> >\n> > 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.\n> >\n> > 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn\n> > but use it.\n> >\n> > 3. It looks obviously bogus (e.g., we do not have a domain name).\n> > Reject it.\n> >\n> > We can move some cases from (2) down to (3), like ...\n> \n> Judging from Thorsten's earlier response, I am afraid no amount of\n> autodetection would help the users of that site. If we were to do\n> something, /etc/gitconfig as you outlined below would be the way to\n> go, even though it makes me feel dirty.\n\nIt was not clear to me whether his site has /etc/mailname. If it does\nnot, then the new rule could be to leave \"/etc/mailname\" in group 2, and\nput \"gethostname/gethostbyname\" into group 3 (right now we do so only\nwhen the results from those functions are obviously not\nfully-qualified).\n\nBut from his description, the machine may even have a split-horizon name\nin /etc/mailname, and we can do nothing at all about that.\n\nEven if it worked, though, I am not sure it would be worth such a rule.\nThe /etc/mailname file is not a standard, so you would effectively be\ncutting off the auto-ident behavior for people on every other system. If\nwe are going to do that, we might as well do it uniformly.\n\n-Peff\n"},{"id":"224989","messageId":"20130810064056.GA3165@elie.Belkin","threadId":"34661","inReplyTo":"20130810061720.GA30185@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-08-10T06:40:56Z","receivedAt":"2013-08-10T06:40:56Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> Even if it worked, though, I am not sure it would be worth such a rule.\n> The /etc/mailname file is not a standard, so you would effectively be\n> cutting off the auto-ident behavior for people on every other system. If\n> we are going to do that, we might as well do it uniformly.\n\nI don't fully follow. Do you mean that because other operating\nsystems choose not to make full use of an /etc/mailname file when it\nis present (and instead use per-MTA configuration), git should not\ntake advantage of it to choose an appropriate email address?\n\nOr do you mean that on non-Debian systems, the FQDN for localhost is\nreliably the mailname, just like on Debian systems /etc/mailname is\nsupposed to be?\n\nConfused,\nJonathan\n"},{"id":"224990","messageId":"20130810064717.GB30185@sigill.intra.peff.net","threadId":"34661","inReplyTo":"20130809231928.GY14690@google.com","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-10T06:47:17Z","receivedAt":"2013-08-10T06:47:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 09, 2013 at 04:19:28PM -0700, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> \n> > Yeah, there are basically three levels of ident:\n> >\n> > 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.\n> >\n> > 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn\n> > but use it.\n> >\n> > 3. It looks obviously bogus (e.g., we do not have a domain name).\n> > Reject it.\n> >\n> > We can move some cases from (2) down to (3), like when we use\n> > gethostname rather than /etc/mailname. But we risk breaking people's\n> > existing setups. I don't think we know how many people rely on the\n> > implicit hostname selection and would be affected. I don't know if there\n> > is a good way to find out short of changing it and seeing who screams.\n> \n> Yes. The result from a reverse DNS lookup is almost never the right\n> mailname.\n\nJust to nitpick, the name we guess is not necessarily from DNS (and if\nthe FQDN comes from DNS, it is not a reverse lookup, but rather\nfollowing the search rules in resolv.conf, or even /etc/hosts). But I\nthink the point is the same: we somehow arrive at the hostname through\nsome accurate means, but that hostname does not reflect the user's\nactual email address.\n\n> * Small installations tend to use a smarthost.\n> * Large installations tend to use more than one machine, and only\n> one machine's name gets the MX record.\n\nI'm not sure the second one is true. Many large installations will MX\nall of their workstations names to a smarthost. So mail to\nuser@randommachine.example.com _is_ deliverable. It has (thankfully)\nbeen a long time since I have been involved in large network IT, but\nthat was standard practice at one time.\n\nBut I think MX records and deliverability is beside the point. Even in a\ncase where we come up with a valid, deliverable address, is that what\nthe user wants to have in their commit history for all time?\n\n> So except for cases where someone doesn't actually care about the\n> recorded author and just has a script making commits (such users\n> already suffer from the \".(none)\" heuristic), I don't think this would\n> hurt anyone.\n\nI think the other case is \"people who actually think the per-machine\ninformation is useful\". I recall Linus arguing for this early on, but he\nseems to have relented. I am not sure whether anyone else in the world\nhas that view (or ever did).\n\nThere are certainly people in the \"I don't care, just make it work\"\ncamp, judging from the repositories I sometimes see on GitHub. Whether\nwe would be harming them (because their workflow breaks) or helping them\n(because they had no idea they had these crappy idents in their history\nand we would be letting them know) is not clear to me, though.\n\n> > We can put a deprecation warning in the release notes, but people tend\n> > to ignore those.\n> \n> Not so much a deprecation warning as an \"Here is one of the more\n> noticeable changes in this release\" announcement.\n\nI meant a warning to give people a chance to comment before the change\ncomes. Following this mailing list is another source for people to find out\nabout it, but I suspect most casual users do not read the list. Perhaps\nit would be worth taking a straw poll over G+ or another more casual\nmedium?\n\n-Peff\n"},{"id":"224991","messageId":"20130810065252.GC30185@sigill.intra.peff.net","threadId":"34661","inReplyTo":"20130810064056.GA3165@elie.Belkin","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-10T06:52:52Z","receivedAt":"2013-08-10T06:52:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 09, 2013 at 11:40:56PM -0700, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> \n> > Even if it worked, though, I am not sure it would be worth such a rule.\n> > The /etc/mailname file is not a standard, so you would effectively be\n> > cutting off the auto-ident behavior for people on every other system. If\n> > we are going to do that, we might as well do it uniformly.\n> \n> I don't fully follow. Do you mean that because other operating\n> systems choose not to make full use of an /etc/mailname file when it\n> is present (and instead use per-MTA configuration), git should not\n> take advantage of it to choose an appropriate email address?\n> \n> Or do you mean that on non-Debian systems, the FQDN for localhost is\n> reliably the mailname, just like on Debian systems /etc/mailname is\n> supposed to be?\n\nSorry to be unclear. I meant that treating /etc/mailname and gethostname\ndifferently might be justified on Debian under the logic \"if you have\n/etc/mailname, that is a trustworthy address, and if you do not, then we\ncannot guess at a trustworthy address (because putting it in\n/etc/mailname is the accepted way to do so on Debian)\".\n\nBut such logic would not extend to other operating systems, where\n/etc/mailname does not have such a status.\n\nI am guessing, too, about what people even put in /etc/mailname. If they\nrelay mail from the machine to a smarthost, do they put the individual\nhostname into /etc/mailname? Or do they put in the domain name that\nrepresents a real deliverable address? If the former, then it is no\nbetter than gethostname anyway.\n\n-Peff\n"},{"id":"224993","messageId":"20130810070300.GB3165@elie.Belkin","threadId":"34661","inReplyTo":"20130810065252.GC30185@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-08-10T07:03:00Z","receivedAt":"2013-08-10T07:03:00Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> Sorry to be unclear. I meant that treating /etc/mailname and gethostname\n> differently might be justified on Debian under the logic \"if you have\n> /etc/mailname, that is a trustworthy address, and if you do not, then we\n> cannot guess at a trustworthy address (because putting it in\n> /etc/mailname is the accepted way to do so on Debian)\".\n>\n> But such logic would not extend to other operating systems, where\n> /etc/mailname does not have such a status.\n\nI thought that on other operating systems people typically don't have\nan /etc/mailname. How does trusting the file when present hurt?\n\n> I am guessing, too, about what people even put in /etc/mailname. If they\n> relay mail from the machine to a smarthost, do they put the individual\n> hostname into /etc/mailname? Or do they put in the domain name that\n> represents a real deliverable address? If the former, then it is no\n> better than gethostname anyway.\n\nDebian policy explains:\n\n\tIf your package needs to know what hostname to use on (for\n\texample) outgoing news and mail messages which are generated\n\tlocally, you should use the file /etc/mailname. It will contain\n\tthe portion after the username and @ (at) sign for email\n\taddresses of users on the machine (followed by a newline).\n\n\tSuch a package should check for the existence of this file when\n\tit is being configured. If it exists, it should be used without\n\tcomment, although an MTA's configuration script may wish to\n\tprompt the user even if it finds that this file exists. If the\n\tfile does not exist, the package should prompt the user for the\n\tvalue (preferably using debconf) and store it in /etc/mailname as\n\twell as using it in the package's configuration. The prompt\n\tshould make it clear that the name will not just be used by that\n\tpackage.\n\nSo on a properly configured Debian system, /etc/mailname contains\nsomething appropriate to put after the @ sign in an email address\nand the sysadmin expects it to be used for that.\n\nAs far as I can tell, to the extent that other distros support\n/etc/mailname, it is only as a side effect of handling that Debian\nrequirement. I don't think e.g. Fedora or Solaris systems typically\nwill have a /etc/mailname file.\n\nI *am* a bit worried about what people might put in /etc/mailname on\nDebian systems when there is no appropriate host to put there (as on\nThorsten's machine).\n\nJonathan\n"},{"id":"224997","messageId":"20130810071407.GA32038@sigill.intra.peff.net","threadId":"34661","inReplyTo":"20130810070300.GB3165@elie.Belkin","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-10T07:14:07Z","receivedAt":"2013-08-10T07:14:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 10, 2013 at 12:03:00AM -0700, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> \n> > Sorry to be unclear. I meant that treating /etc/mailname and gethostname\n> > differently might be justified on Debian under the logic \"if you have\n> > /etc/mailname, that is a trustworthy address, and if you do not, then we\n> > cannot guess at a trustworthy address (because putting it in\n> > /etc/mailname is the accepted way to do so on Debian)\".\n> >\n> > But such logic would not extend to other operating systems, where\n> > /etc/mailname does not have such a status.\n> \n> I thought that on other operating systems people typically don't have\n> an /etc/mailname. How does trusting the file when present hurt?\n\nI guess I am not explaining myself well. Trusting the file when present\ndoes not hurt at all. But the logic above is making assumptions about\nthe state when the file is _not_ present (i.e., the \"if you do not...\"\nclause above). On Debian, we might assume that if /etc/mailname is not\npresent that this is a clue that the machine cannot produce a useful\naddress. But on other operating systems, that is not a useful clue (it\nis simply that /etc/mailname is not used on that system). Dying on such\na system when /etc/mailname is not present would be a regression.\n\nDoes that make more sense?\n\n> I *am* a bit worried about what people might put in /etc/mailname on\n> Debian systems when there is no appropriate host to put there (as on\n> Thorsten's machine).\n\nYeah. Or even in a split-horizon setup where the mail is deliverable but\ndoes not reflect the public identity of the user. I think we are getting\ndown to the question I mentioned elsewhere: it is not about whether we\nhave a deliverable address or not, but what users want to cement in\nhistory for all time as their identity.\n\nSo thinking too much about /etc/mailname versus gethostname is probably\nnot useful. Either it is worth breaking the few (if any) users who\ndepend on the auto ident in favor of fewer accidental implicit idents\nmaking their way into the wild, or it is not.\n\n-Peff\n"},{"id":"225007","messageId":"52060EF9.2040504@alum.mit.edu","threadId":"34661","inReplyTo":"20130810064717.GB30185@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-08-10T09:59:21Z","receivedAt":"2013-08-10T09:59:21Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 08/10/2013 08:47 AM, Jeff King wrote:\n> But I think MX records and deliverability is beside the point. Even in a\n> case where we come up with a valid, deliverable address, is that what\n> the user wants to have in their commit history for all time?\n\nI intentionally don't set user.email in my ~/.gitconfig because I use\ndifferent identities (on the same machine) depending on what project I\nam committing to (open-source vs. work). After I clone a repo, I *rely*\non Git reminding me to set user.email on my first commit, because I\ninvariably forget to set it myself. And for me, *any* universal,\nheuristically-determined email address would be wrong for me for at\nleast some repos.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"225011","messageId":"20130810102834.GA6237@sigill.intra.peff.net","threadId":"34661","inReplyTo":"52060EF9.2040504@alum.mit.edu","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-10T10:28:35Z","receivedAt":"2013-08-10T10:28:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:\n\n> On 08/10/2013 08:47 AM, Jeff King wrote:\n> > But I think MX records and deliverability is beside the point. Even in a\n> > case where we come up with a valid, deliverable address, is that what\n> > the user wants to have in their commit history for all time?\n> \n> I intentionally don't set user.email in my ~/.gitconfig because I use\n> different identities (on the same machine) depending on what project I\n> am committing to (open-source vs. work). After I clone a repo, I *rely*\n> on Git reminding me to set user.email on my first commit, because I\n> invariably forget to set it myself. And for me, *any* universal,\n> heuristically-determined email address would be wrong for me for at\n> least some repos.\n\nSo if I understand your use case, then you would be even happier if\nrather than giving a warning, git simply barfed and said \"please set\nyour identity before committing\"?\n\n-Peff\n"},{"id":"225013","messageId":"5206273C.3050803@alum.mit.edu","threadId":"34661","inReplyTo":"20130810102834.GA6237@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-08-10T11:42:52Z","receivedAt":"2013-08-10T11:42:52Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 08/10/2013 12:28 PM, Jeff King wrote:\n> On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:\n> \n>> On 08/10/2013 08:47 AM, Jeff King wrote:\n>>> But I think MX records and deliverability is beside the point. Even in a\n>>> case where we come up with a valid, deliverable address, is that what\n>>> the user wants to have in their commit history for all time?\n>>\n>> I intentionally don't set user.email in my ~/.gitconfig because I use\n>> different identities (on the same machine) depending on what project I\n>> am committing to (open-source vs. work). After I clone a repo, I *rely*\n>> on Git reminding me to set user.email on my first commit, because I\n>> invariably forget to set it myself. And for me, *any* universal,\n>> heuristically-determined email address would be wrong for me for at\n>> least some repos.\n> \n> So if I understand your use case, then you would be even happier if\n> rather than giving a warning, git simply barfed and said \"please set\n> your identity before committing\"?\n\nYes, definitely.\n\nFor the particular use case that I described, I wouldn't mind setting a\nglobal setting \"barfOnMissingEmail = true\" because I always use the same\nLinux account. But for other uses cases that arise at my company,\npeople have to jump around from one computer to another, and it would be\nmore convenient if the barfing behavior was the default without the need\nfor a setting.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"225018","messageId":"Pine.BSM.4.64L.1308101202260.28970@herc.mirbsd.org","threadId":"34661","inReplyTo":"20130810102834.GA6237@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Thorsten Glaser","fromEmail":"tg@mirbsd.de","sentAt":"2013-08-10T12:06:08Z","receivedAt":"2013-08-10T12:06:08Z","isPatch":false,"sender":{"key":"tg@mirbsd.de","avatar":"https://gravatar.com/avatar/e4bb7217fcb56def9c570cc3803933454cebf7617d95e8fa82d3b56141c53413?d=mp&s=160"},"body":"Jeff King dixit:\n\n>It was not clear to me whether his site has /etc/mailname. If it does\n\nSome may, some may not but…\n\n>But from his description, the machine may even have a split-horizon name\n>in /etc/mailname, and we can do nothing at all about that.\n\n… that won’t happen. The problem is that they may have\nthe correct domain there but the localpart will still\nbe wrong because Kolab localparts are not Unix usernames.\n\n\nJonathan Nieder dixit:\n\n>I thought that on other operating systems people typically don't have\n>an /etc/mailname. How does trusting the file when present hurt?\n\nRight, MirBSD doesn’t have it, and I don’t think OpenBSD\nadded it since we forked.\n\n\nJeff King dixit:\n\n>On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:\n>\n>> I intentionally don't set user.email in my ~/.gitconfig because I use\n>> different identities (on the same machine) depending on what project I\n\nFor me that’s also true, but I set a default one at the moment\nwhich is still better than having an unroutable one (on my private\nlaptop, ${unix_username}@${fqdn} does work, but only as long as my\nlaptop is powered on, has got IPv6 Internet, and the sending MTA\nhas IPv6 Internet, so… it’s mostly unroutable).\n\nWhile I used a fallback for this scenario (me, privately), I’d\nalso benefit from git refusing to accept commits by default.\n\n>So if I understand your use case, then you would be even happier if\n>rather than giving a warning, git simply barfed and said \"please set\n>your identity before committing\"?\n\nExactly. That’s what I think he said, and what I asked for too.\n\nThanks,\n//mirabilos (working with many OSS projects)\n-- \nI believe no one can invent an algorithm. One just happens to hit upon it\nwhen God enlightens him. Or only God invents algorithms, we merely copy them.\nIf you don't believe in God, just consider God as Nature if you won't deny\nexistence.\t\t-- Coywolf Qi Hunt\n"},{"id":"225016","messageId":"87bo55912e.fsf@igel.home","threadId":"34661","inReplyTo":"20130810102834.GA6237@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-08-10T12:34:33Z","receivedAt":"2013-08-10T12:34:33Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Jeff King writes:\n\n> So if I understand your use case, then you would be even happier if\n> rather than giving a warning, git simply barfed and said \"please set\n> your identity before committing\"?\n\nFWIW, this is what both hg and bzr do.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"225029","messageId":"7vvc3d1o01.fsf@alter.siamese.dyndns.org","threadId":"34661","inReplyTo":"52060EF9.2040504@alum.mit.edu","subject":"Re: git should not use a default user.email config value","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-10T16:58:38Z","receivedAt":"2013-08-10T16:58:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> On 08/10/2013 08:47 AM, Jeff King wrote:\n>> But I think MX records and deliverability is beside the point. Even in a\n>> case where we come up with a valid, deliverable address, is that what\n>> the user wants to have in their commit history for all time?\n>\n> I intentionally don't set user.email in my ~/.gitconfig because I use\n> different identities (on the same machine) depending on what project I\n> am committing to (open-source vs. work). After I clone a repo, I *rely*\n> on Git reminding me to set user.email on my first commit, because I\n> invariably forget to set it myself. And for me, *any* universal,\n> heuristically-determined email address would be wrong for me for at\n> least some repos.\n\nInteresting.\n\nIf we tweaked the \"template\" mechanism used by the init_db() more\naccessible, because both \"git init\" and \"git clone\" know to honor\nthe templates, you could prepare ~/.git-profile/{work,open}/config\nfiles that define user.email/user.name in there. The existing way\nto use \"template\" mechanism is a bit too heavy-handed in the sense\nthat if you want to tweak the \"config\" using it, you also have to\nhave everything else in the templates, which makes it unwieldy to\nuse. Perhaps we need a lighter-weight mechanism\n\n\tgit init --profile=open\n git clone --profile=open git://git.kernel.org/git.git\n\nthat does:\n\n (1) exactly the same as what the current code do without the new\n option, then\n\n (2) configure \"include.path\" to point at \"~/.git-profile/open\" at\n the very end\n\nor something? Then the \"profile\" files can have a shared setting\nfor the kinds of projects (the above examples are \"open\" projects,\nand you would have another kind, \"work\" projects) that will apply to\nall the projects of that nature. You update ~/.git-profile/open and\nthen that update applys to all repositories on your open projects.\n\nThe above is a tangent and independent from allowing the site owner\nto set \"user.requireExplicit = true\" in /etc/gitconfig.\n"},{"id":"225037","messageId":"20130811000654.GA23413@pug.qqx.org","threadId":"34661","inReplyTo":"52060EF9.2040504@alum.mit.edu","subject":"Re: git should not use a default user.email config value","fromName":"Aaron Schrab","fromEmail":"aaron@schrab.com","sentAt":"2013-08-11T00:06:54Z","receivedAt":"2013-08-11T00:06:54Z","isPatch":false,"sender":{"key":"aaron@schrab.com","avatar":"https://avatars.githubusercontent.com/u/39620?v=4"},"body":"At 11:59 +0200 10 Aug 2013, Michael Haggerty wrote:\n>I intentionally don't set user.email in my ~/.gitconfig because I use\n>different identities (on the same machine) depending on what project I\n>am committing to (open-source vs. work). After I clone a repo, I *rely*\n>on Git reminding me to set user.email on my first commit, because I\n>invariably forget to set it myself. And for me, *any* universal,\n>heuristically-determined email address would be wrong for me for at\n>least some repos.\n\nI was in a similar situation for awhile. Except in my case I had $EMAIL \nset for other reasons, so I didn't get the reminder even if git wasn't \nconfigured.\n\nThe solution I came up with was to use a template directory to have the \nfollowing script installed as a pre-commit hook in all new repos:\n\n #!/bin/sh\n git config user.email > /dev/null && exit\n echo 'Set email address with `git config user.email` first' >&2\n exit 1\n"},{"id":"225102","messageId":"CAH5451nHfOaBzFzkrGvw+TyRj==cVpKF_QdXsTxnn5tTr1c0dw@mail.gmail.com","threadId":"34661","inReplyTo":"7vvc3d1o01.fsf@alter.siamese.dyndns.org","subject":"Re: git should not use a default user.email config value","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-08-12T11:52:45Z","receivedAt":"2013-08-12T11:52:45Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 11 August 2013 02:58, Junio C Hamano wrote:\n> Perhaps we need a lighter-weight mechanism\n>\n> git init --profile=open\n> git clone --profile=open git://git.kernel.org/git.git\n\nThis is something I would definitely use.\n\nAll of my work git directories are in a separate folder to my other\ngit directories, and as such it would be extremely convenient if every\nrepository under that folder defaulted to the same profile. That may\nbe asking for too much though!\n\nRegards,\n\nAndrew Ardill\n"},{"id":"225105","messageId":"20130812123921.GA16088@sigill.intra.peff.net","threadId":"34661","inReplyTo":"CAH5451nHfOaBzFzkrGvw+TyRj==cVpKF_QdXsTxnn5tTr1c0dw@mail.gmail.com","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-12T12:39:21Z","receivedAt":"2013-08-12T12:39:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:\n\n> On 11 August 2013 02:58, Junio C Hamano wrote:\n> > Perhaps we need a lighter-weight mechanism\n> >\n> > git init --profile=open\n> > git clone --profile=open git://git.kernel.org/git.git\n> \n> This is something I would definitely use.\n> \n> All of my work git directories are in a separate folder to my other\n> git directories, and as such it would be extremely convenient if every\n> repository under that folder defaulted to the same profile. That may\n> be asking for too much though!\n\nWe could do something like the patch below, which allows:\n\n $ git config --global include./magic/.path .gitconfig-magic\n\nto read ~/.gitconfig-magic only when we are in a repository with a\ndirectory component \"/magic/\".\n\nI can see how such a thing might be useful, even though I do not have a\nuse for that much flexibility myself. I find myself doing this trick for\nthings like editor settings, but not for git config. So do not count\nthis necessarily as a vote for doing this; it was a fun exercise for me\nthat others might find useful.\n\nComparing this against a \"profile\" type of solution:\n\n 1. This handles only config, not full templates (so no custom hooks;\n however, we could provide a level of indirection for hooks inside\n the config).\n\n 2. Unlike a profile that is used during repository init, this is\n resolved at runtime, so it keeps up to date as you change\n ~/.gitconfig-magic.\n\n---\ndiff --git a/config.c b/config.c\nindex e13a7b6..a31dc85 100644\n--- a/config.c\n+++ b/config.c\n@@ -119,10 +119,45 @@ int git_config_include(const char *var, const char *value, void *data)\n \treturn ret;\n }\n \n+static NORETURN void die_bad_regex(int err, regex_t *re)\n+{\n+\tchar errbuf[1024];\n+\tregerror(err, re, errbuf, sizeof(errbuf));\n+\tif (cf && cf->name)\n+\t\tdie(\"bad regex (at %s:%d): %s\", cf->name, cf->linenr, errbuf);\n+\telse\n+\t\tdie(\"bad regex: %s\", errbuf);\n+}\n+\n+static int match_repo_path(const char *re_str)\n+{\n+\tregex_t re;\n+\tint ret;\n+\tconst char *repo_path;\n+\n+\tret = regcomp(&re, re_str, REG_EXTENDED);\n+\tif (ret)\n+\t\tdie_bad_regex(ret, &re);\n+\n+\trepo_path = absolute_path(get_git_dir());\n+\tret = regexec(&re, repo_path, 0, NULL, 0);\n+\tregfree(&re);\n+\treturn !ret;\n+}\n+\n+static int match_repo_path_mem(const char *re_buf, int len)\n+{\n+\tchar *re_str = xmemdupz(re_buf, len);\n+\tint ret = match_repo_path(re_str);\n+\tfree(re_str);\n+\treturn ret;\n+}\n+\n int git_config_include(const char *var, const char *value, void *data)\n {\n \tstruct config_include_data *inc = data;\n-\tconst char *type;\n+\tconst char *match, *type;\n+\tint match_len;\n \tint ret;\n \n \t/*\n@@ -133,8 +168,9 @@ int git_config_include(const char *var, const char *value, void *data)\n \tif (ret < 0)\n \t\treturn ret;\n \n-\ttype = skip_prefix(var, \"include.\");\n-\tif (!type)\n+\tif (parse_config_key(var, \"include\", &match, &match_len, &type))\n+\t\treturn ret;\n+\tif (match && !match_repo_path_mem(match, match_len))\n \t\treturn ret;\n \n \tif (!strcmp(type, \"path\"))\n"},{"id":"225106","messageId":"rmieh9zdqcf.fsf@fnord.ir.bbn.com","threadId":"34661","inReplyTo":"20130810102834.GA6237@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-08-12T12:51:44Z","receivedAt":"2013-08-12T12:51:44Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJeff King writes:\n\n> On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:\n>\n>> I intentionally don't set user.email in my ~/.gitconfig because I use\n>> different identities (on the same machine) depending on what project I\n>> am committing to (open-source vs. work). After I clone a repo, I *rely*\n>> on Git reminding me to set user.email on my first commit, because I\n>> invariably forget to set it myself. And for me, *any* universal,\n>> heuristically-determined email address would be wrong for me for at\n>> least some repos.\n>\n> So if I understand your use case, then you would be even happier if\n> rather than giving a warning, git simply barfed and said \"please set\n> your identity before committing\"?\n\nI also think it's a bug that git will create commits without an\nexplicitly-set author. I've seen multiple cases of the author being\nsomething unreasonable in a shared/official repository because of this.\nOne was a person's personal email address on a work-repo commit,\napparently because on Mac there was some magic extraction of primary\nemail address from Mail.app (but I'm not 100% clear on what happened).\nIf name/mail are not explicitly set, failing and making the user set\nthem seems like the right thing.\n\nI find all the discussion of /etc/mailname to be a bit perplexing. The\nnotion that the externally-visible email of a person making a commit\nshould be the same as if they sent mail from that machine seems to be a\nbit of a stretch. And their username might be different. I don't think\nit's possible to reliably figure out what ought to be in the git author\nfield.\n\nAnother reason to fail rather than use a possibly-wrong default is that\nit's very difficult (if not impossible, depending on local CM policy\nabout forced updates in shared repos) to recover from pushing a commit\nwith a bad email address. (And the people that don't set their email\nright are the same people that won't run \"git log -p @{u}..\" before\npushing.) But failing and having to set it manually is easy (people who\nare already competent will be slowed down a minute or two, and the\nothers need to learn anyway), results in something that should have been\ndone anyway, and has no long-term negative consequences.\n\n"},{"id":"225107","messageId":"5208DAF5.3040006@alum.mit.edu","threadId":"34661","inReplyTo":"20130812123921.GA16088@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-08-12T12:54:13Z","receivedAt":"2013-08-12T12:54:13Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 08/12/2013 02:39 PM, Jeff King wrote:\n> On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:\n> \n>> On 11 August 2013 02:58, Junio C Hamano wrote:\n>>> Perhaps we need a lighter-weight mechanism\n>>>\n>>> git init --profile=open\n>>> git clone --profile=open git://git.kernel.org/git.git\n>>\n>> This is something I would definitely use.\n>>\n>> All of my work git directories are in a separate folder to my other\n>> git directories, and as such it would be extremely convenient if every\n>> repository under that folder defaulted to the same profile. That may\n>> be asking for too much though!\n> \n> We could do something like the patch below, which allows:\n> \n> $ git config --global include./magic/.path .gitconfig-magic\n> \n> to read ~/.gitconfig-magic only when we are in a repository with a\n> directory component \"/magic/\".\n> \n> I can see how such a thing might be useful, even though I do not have a\n> use for that much flexibility myself. I find myself doing this trick for\n> things like editor settings, but not for git config. So do not count\n> this necessarily as a vote for doing this; it was a fun exercise for me\n> that others might find useful.\n\nWe could satisfy a whole class of wishes by supporting\nuser-wide/system-wide git hooks like\n\n ~/.githooks/{pre,post}-clone /etc/githooks/{pre,post}-clone\n ~/.githooks/{pre,post}-init /etc/githooks/{pre,post}-init\n\nI suppose similar functionality could be implemented via git aliases,\nbut hook scripts are easier to install and share.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"225108","messageId":"CAH5451=PK15n4U-3Mb_TLevF3-r+vrpk1PXD15Oo1A2KFc5i_w@mail.gmail.com","threadId":"34661","inReplyTo":"20130812123921.GA16088@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-08-12T13:01:03Z","receivedAt":"2013-08-12T13:01:03Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 12 August 2013 22:39, Jeff King wrote:\n> We could do something like the patch below, which allows:\n>\n> $ git config --global include./magic/.path .gitconfig-magic\n>\n> to read ~/.gitconfig-magic only when we are in a repository with a\n> directory component \"/magic/\".\n\nThanks, this looks great! I'll have a play with it tomorrow.\n\nWould locally configured config options override this one? From a\nquick read of the patch there doesn't look like there is a way of\nturning this off for a specific repository, but perhaps that is\nunnecessary. I think after a bit of use the edge cases will be a bit\nclearer.\n\nAgain thanks, this will scratch an itch I didn't even realise I had.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"225112","messageId":"20130812154520.GA18215@sigill.intra.peff.net","threadId":"34661","inReplyTo":"CAH5451=PK15n4U-3Mb_TLevF3-r+vrpk1PXD15Oo1A2KFc5i_w@mail.gmail.com","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-12T15:45:21Z","receivedAt":"2013-08-12T15:45:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:\n\n> On 12 August 2013 22:39, Jeff King wrote:\n> > We could do something like the patch below, which allows:\n> >\n> > $ git config --global include./magic/.path .gitconfig-magic\n> >\n> > to read ~/.gitconfig-magic only when we are in a repository with a\n> > directory component \"/magic/\".\n> \n> Thanks, this looks great! I'll have a play with it tomorrow.\n> \n> Would locally configured config options override this one? From a\n> quick read of the patch there doesn't look like there is a way of\n> turning this off for a specific repository, but perhaps that is\n> unnecessary. I think after a bit of use the edge cases will be a bit\n> clearer.\n\nYes, the usual config and include rules apply; the patch just selectively\nignores the include based on the subsection regex. So if you put the\nmagic include in your ~/.gitconfig, anything in the repo's .git/config\nwill override it.\n\nBut that also means the usual restrictions apply, too. There is no way\nto \"unset\" a variable as if it had never been specified in the first\nplace. And multi-valued variables will always append (e.g.,\nremote.*.fetch).\n\nThe matcher is a regex, so depending on how tortured you want your regex\nto get, you can probably exclude a particular directory with that. :)\n\n-Peff\n"},{"id":"225113","messageId":"20130812154904.GB18215@sigill.intra.peff.net","threadId":"34661","inReplyTo":"5208DAF5.3040006@alum.mit.edu","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-12T15:49:04Z","receivedAt":"2013-08-12T15:49:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 12, 2013 at 02:54:13PM +0200, Michael Haggerty wrote:\n\n> We could satisfy a whole class of wishes by supporting\n> user-wide/system-wide git hooks like\n> \n> ~/.githooks/{pre,post}-clone /etc/githooks/{pre,post}-clone\n> ~/.githooks/{pre,post}-init /etc/githooks/{pre,post}-init\n> \n> I suppose similar functionality could be implemented via git aliases,\n> but hook scripts are easier to install and share.\n\nI don't mind something like that, as it is very flexible. But I have a\nfeeling most uses would end up just symlinking some template hooks or\nconfig. At which point we might be better serving the user to provide a\nsolution that is simpler to use (e.g., a ~/.githooks directory that is\nchecked for all hooks; the tricky part there would be making rules for\nthe case that there are system, user, and repo-level scripts for a\nparticular hook).\n\n-Peff\n"},{"id":"225133","messageId":"vpqsiyehv1j.fsf@anie.imag.fr","threadId":"34661","inReplyTo":"7vvc3d1o01.fsf@alter.siamese.dyndns.org","subject":"Re: git should not use a default user.email config value","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-13T08:08:56Z","receivedAt":"2013-08-13T08:08:56Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> (2) configure \"include.path\" to point at \"~/.git-profile/open\" at\n> the very end\n\nI'd rather have it ~/.config/git/profile/ (or\n$XDG_CONFIG_HOME/git/profile if $XDG_CONFIG_HOME is set), but the\nproposal makes sense.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"225134","messageId":"vpq4nauhubt.fsf@anie.imag.fr","threadId":"34661","inReplyTo":"20130809194214.GV14690@google.com","subject":"Re: git should not use a default user.email config value","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-13T08:24:22Z","receivedAt":"2013-08-13T08:24:22Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder writes:\n\n> Hi Thorsten,\n>\n> Thorsten Glaser wrote[1]:\n>\n>> git config user.email SHOULD NOT default to $(id -un)@$(hostname -f)\n>> because just too many cow-orkers seem to be unable to follow basic\n>> instructions\n>\n> Heh.\n>\n> Can you say a little more about your setup? In a university\n> environment with sysadmin-managed email and /etc/mailname set up\n> correctly it is handy that people can start working without doing\n> anything special to configure git's \"[user] email\" setting.\n\nI also work with a university environment. The guessed user.email is\nalmost right (actually, it's not the official email address, but an\ninternal one we ask students not to use). Still, I'd love to see Git\nerror out by default, as most students use Git from several machines.\nThey usually learn and write their first ~/.gitconfig on the school's\nmachines, and then start working from their personal laptops, where the\nguessed user.email is plain wrong.\n\nWe do teach them to set user.email in ~/.gitconfig as a very first step,\nbut many don't (because they don't read the tutorial, or because they do\nsomething wrong like putting .gitconfig in the wrong directory). We do\ntell them to set up ~/.gitconfig on every host they work from, but many\ndon't either. And unfortunately, the warning is not scary enough for\nsome of them :-\\ (\"Err, did I get a warning? where?\").\n\nAn opt-in auto-detection would be cool for people who really work in a\ncontrolled environment, so that the sysadmin could enable it from\n/etc/gitconfig.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"225135","messageId":"vpqwqnqgfj9.fsf@anie.imag.fr","threadId":"34661","inReplyTo":"CAMP44s1SxSd-cM_P-JL2+skB6mDmar_QwFv9mYp5BrXUKTz61w@mail.gmail.com","subject":"Re: git should not use a default user.email config value","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-13T08:29:14Z","receivedAt":"2013-08-13T08:29:14Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> This is how to implement that:\n>\n> From f1feaa05ce3772d8006078c4aeabcbd55b52d58e Mon Sep 17 00:00:00 2001\n> From: Felipe Contreras 2nd \n> Date: Tue, 13 Nov 2012 07:33:12 +0100\n> Subject: [PATCH] ident: don't allow implicit email addresses\n>\n> Signed-off-by: Felipe Contreras \n> ---\n> ident.c | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/ident.c b/ident.c\n> index 1c123e6..85fc729 100644\n> --- a/ident.c\n> +++ b/ident.c\n> @@ -301,9 +301,9 @@ const char *fmt_ident(const char *name, const char *email,\n> \t}\n>\n> \tif (strict && email == git_default_email.buf &&\n> -\t strstr(email, \"(none)\")) {\n> +\t\t!(user_ident_explicitly_given & IDENT_MAIL_GIVEN)) {\n> \t\tfputs(env_hint, stderr);\n> -\t\tdie(\"unable to auto-detect email address (got '%s')\", email);\n> +\t\tdie(\"no explicit email address\");\n> \t}\n>\n> \tif (want_date) {\n\nThat's a first step, but something should also be done in\nbuiltin/commit.c, which currently displays a detailed warning\n(implicit_ident_advice) /after/ performing the commit. I think your\npatch would turn this warning into dead code.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"225136","messageId":"Pine.BSM.4.64L.1308130837390.20692@herc.mirbsd.org","threadId":"34661","inReplyTo":"vpq4nauhubt.fsf@anie.imag.fr","subject":"Re: git should not use a default user.email config value","fromName":"Thorsten Glaser","fromEmail":"tg@mirbsd.de","sentAt":"2013-08-13T08:39:29Z","receivedAt":"2013-08-13T08:39:29Z","isPatch":false,"sender":{"key":"tg@mirbsd.de","avatar":"https://gravatar.com/avatar/e4bb7217fcb56def9c570cc3803933454cebf7617d95e8fa82d3b56141c53413?d=mp&s=160"},"body":"Matthieu Moy dixit:\n\n>An opt-in auto-detection would be cool for people who really work in a\n>controlled environment, so that the sysadmin could enable it from\n\nSounds like a plan ;-)\n\nI think with several people chiming in on this, while that proposal\nwould affect a majority of people, it would do so in a less intrusive\nway as the current behaviour of autodetection which negatively affects\nsome users, although not few either, in a strong way.\n\nbye,\n//mirabilos\n-- \n> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig\n> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)\nHallooooo, ich bin der Holger (\"Hallo Holger!\"), und ich bin ebenfalls\n... pine-User, und das auch noch gewohnheitsmäßig (\"Oooooooohhh\"). [aus dasr]\n"},{"id":"225138","messageId":"CAH5451=WKXUNzovXquFii=EdkeQXJEQ96_CRRebgQW6ow_19VA@mail.gmail.com","threadId":"34661","inReplyTo":"20130812154520.GA18215@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-08-13T11:05:40Z","receivedAt":"2013-08-13T11:05:40Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:\n>On 12 August 2013 22:39, Jeff King wrote:\n>> We could do something like the patch below, which allows:\n>>\n>> $ git config --global include./magic/.path .gitconfig-magic\n>>\n>> to read ~/.gitconfig-magic only when we are in a repository with a\n>> directory component \"/magic/\".\n>\n> Thanks, this looks great! I'll have a play with it tomorrow.\n\nI applied this on top of latest next (1da3ebde8999d07), and it worked\nperfectly for my use case.\n\nFor what it's worth, it also passed the test suite!\n\nWould be great to see this, or something on the same theme, get into\nmaster. I'd be happy to review patches/write tests/write documentation\nif needed.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"225139","messageId":"20130813114635.GA16506@sigill.intra.peff.net","threadId":"34661","inReplyTo":"CAH5451=WKXUNzovXquFii=EdkeQXJEQ96_CRRebgQW6ow_19VA@mail.gmail.com","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-13T11:46:35Z","receivedAt":"2013-08-13T11:46:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 13, 2013 at 09:05:40PM +1000, Andrew Ardill wrote:\n\n> I applied this on top of latest next (1da3ebde8999d07), and it worked\n> perfectly for my use case.\n> \n> For what it's worth, it also passed the test suite!\n> \n> Would be great to see this, or something on the same theme, get into\n> master. I'd be happy to review patches/write tests/write documentation\n> if needed.\n\nLike I said, I do not have a particular use for it, but I don't think it\nwould hurt anybody who does not use it. If you want to polish it up into\na real patch with docs and tests, I don't mind.\n\nThe only downside I can think of is that we might want to use the\nsubsection in \"include.SUBSECTION.*\" for some other limiting conditions\n(e.g., \"only include this config when running version >= X.Y\", or even\n\"include only when environment variable FOO is true\").\n\nI guess we could do something like:\n\n [include \"repo:...your regex here...\"]\n path = .gitconfig-only-for-some-repos\n [include \"env:USE_MY_MAGIC_CONFIG\"]\n path = .gitconfig-only-when-magic-env-set\n\nAdding the \"repo:\" prefix for this repo-dir matching is pretty trivial.\nAdding a similar env-matching is only slightly less trivial; but does\nanybody actually want it?\n\n-Peff\n"},{"id":"225140","messageId":"20130813120530.GA622@sigill.intra.peff.net","threadId":"34661","inReplyTo":"20130813114635.GA16506@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-13T12:05:30Z","receivedAt":"2013-08-13T12:05:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 13, 2013 at 07:46:35AM -0400, Jeff King wrote:\n\n> The only downside I can think of is that we might want to use the\n> subsection in \"include.SUBSECTION.*\" for some other limiting conditions\n> (e.g., \"only include this config when running version >= X.Y\", or even\n> \"include only when environment variable FOO is true\").\n> \n> I guess we could do something like:\n> \n> [include \"repo:...your regex here...\"]\n> path = .gitconfig-only-for-some-repos\n> [include \"env:USE_MY_MAGIC_CONFIG\"]\n> path = .gitconfig-only-when-magic-env-set\n> \n> Adding the \"repo:\" prefix for this repo-dir matching is pretty trivial.\n> Adding a similar env-matching is only slightly less trivial; but does\n> anybody actually want it?\n\nHere it is with the \"repo:\" prefix, if you want to build on that.\n\nAdding the \"env\" spec is as easy as doing this on top:\n\n\n\tdiff --git a/config.c b/config.c\n\tindex f1ca6fa..64ba141 100644\n\t--- a/config.c\n\t+++ b/config.c\n\t@@ -150,6 +150,8 @@ static int match_config_include(const char *spec)\n\t \tconst char *val;\n\t \tif ((val = skip_prefix(spec, \"repo:\")))\n\t \t\treturn match_repo_path(val);\n\t+\tif ((val = skip_prefix(spec, \"env:\")))\n\t+\t\treturn git_env_bool(val, 0);\n\t \n\t \t/* Unknown specs are considered \"no match\". */\n\t \treturn 0;\n\n---\ndiff --git a/config.c b/config.c\nindex e13a7b6..f1ca6fa 100644\n--- a/config.c\n+++ b/config.c\n@@ -119,10 +119,55 @@ int git_config_include(const char *var, const char *value, void *data)\n \treturn ret;\n }\n \n+static NORETURN void die_bad_regex(int err, regex_t *re)\n+{\n+\tchar errbuf[1024];\n+\tregerror(err, re, errbuf, sizeof(errbuf));\n+\tif (cf && cf->name)\n+\t\tdie(\"bad regex (at %s:%d): %s\", cf->name, cf->linenr, errbuf);\n+\telse\n+\t\tdie(\"bad regex: %s\", errbuf);\n+}\n+\n+static int match_repo_path(const char *re_str)\n+{\n+\tregex_t re;\n+\tint ret;\n+\tconst char *repo_path;\n+\n+\tret = regcomp(&re, re_str, REG_EXTENDED);\n+\tif (ret)\n+\t\tdie_bad_regex(ret, &re);\n+\n+\trepo_path = absolute_path(get_git_dir());\n+\tret = regexec(&re, repo_path, 0, NULL, 0);\n+\tregfree(&re);\n+\treturn !ret;\n+}\n+\n+static int match_config_include(const char *spec)\n+{\n+\tconst char *val;\n+\tif ((val = skip_prefix(spec, \"repo:\")))\n+\t\treturn match_repo_path(val);\n+\n+\t/* Unknown specs are considered \"no match\". */\n+\treturn 0;\n+}\n+\n+static int match_config_include_mem(const char *spec, int spec_len)\n+{\n+\tchar *spec_str = xmemdupz(spec, spec_len);\n+\tint ret = match_config_include(spec_str);\n+\tfree(spec_str);\n+\treturn ret;\n+}\n+\n int git_config_include(const char *var, const char *value, void *data)\n {\n \tstruct config_include_data *inc = data;\n-\tconst char *type;\n+\tconst char *match, *type;\n+\tint match_len;\n \tint ret;\n \n \t/*\n@@ -133,8 +178,9 @@ int git_config_include(const char *var, const char *value, void *data)\n \tif (ret < 0)\n \t\treturn ret;\n \n-\ttype = skip_prefix(var, \"include.\");\n-\tif (!type)\n+\tif (parse_config_key(var, \"include\", &match, &match_len, &type))\n+\t\treturn ret;\n+\tif (match && !match_config_include_mem(match, match_len))\n \t\treturn ret;\n \n \tif (!strcmp(type, \"path\"))\n"},{"id":"225141","messageId":"CAH5451nxgpa4Q-BpwhD7yD6V6_LWBP=+oEDR3u0eGErSWNEBbQ@mail.gmail.com","threadId":"34661","inReplyTo":"20130813114635.GA16506@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-08-13T12:52:34Z","receivedAt":"2013-08-13T12:52:34Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 13 August 2013 21:46, Jeff King wrote:\n\n> Like I said, I do not have a particular use for it, but I don't think it\n> would hurt anybody who does not use it. If you want to polish it up into\n> a real patch with docs and tests, I don't mind.\n\nI'll have a go at this.\n\n> The only downside I can think of is that we might want to use the\n> subsection in \"include.SUBSECTION.*\" for some other limiting conditions\n> (e.g., \"only include this config when running version >= X.Y\", or even\n> \"include only when environment variable FOO is true\").\n\nIt seems as though gitconfig doesn't have a standard way of dealing\nwith 'sub-subsections', which is essentially what this is trying to\nimplement.\n\nIt makes sense that there could be different 'modes' of includes.\nThese could be the ones you mentioned already, such as repo and env,\nbut could also be things like branch where the config changes\ndepending on which branch you are on. Ideally, multiple entries per\nmode would be allowed.\nImplementing all that initially would be overkill however if this sort\nof functionality is desirable the ability to easily add new modes\nwould be a great boon down the track.\n\nThe four pieces of information we need to include are that this is an\ninclude, the path to the include, the mode, and the mode specific\nparameter. Your proposal is to allow the sub-subsection by\nconcatenating with a \":\" like this\n\n[include \":]\n path = \n\nAlternatively, we could allow chaining of subsections (couldn't find\nany previous discussion on this) by adding whitespace between each\nsubsection. Seems like lots of potentially unnecessary work, but maybe\nthis has already been discussed or is the most appropriate way of\ndoing it.\n\n$ git config --global include.repo./magic/.path ~/.gitconfig-magic\n\n[include repo \"/magic/\"]\n path = .gitconfig-magic\n\nWe could also require a unique key that grouped the options together.\nThis seems like the easiest and most flexible method, and doesn't\nrequire any 'special' considerations for the subsection. It would be\nharder for a user to configure, and the concept of a mode seems less\nintuitive.\n\n$ git config --global include.magicrepos.mode repo\n$ git config --global include.magicrepos.param /magic/\n$ git config --global include.magicrepos.path ~/.gitconfig-magic\n\n[include \"magicrepos\"]\n mode = repo\n param = \"/magic/\"\n path = ~/.gitconfig-magic\n\nOf the three I probably think the subsection chaining is the nicest\noverall, though your original \"repo:\" proposal seems to be the easiest\nto implement.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"225146","messageId":"20130813155345.GA23391@sigill.intra.peff.net","threadId":"34661","inReplyTo":"CAH5451nxgpa4Q-BpwhD7yD6V6_LWBP=+oEDR3u0eGErSWNEBbQ@mail.gmail.com","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-13T15:53:46Z","receivedAt":"2013-08-13T15:53:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 13, 2013 at 10:52:34PM +1000, Andrew Ardill wrote:\n\n> > The only downside I can think of is that we might want to use the\n> > subsection in \"include.SUBSECTION.*\" for some other limiting conditions\n> > (e.g., \"only include this config when running version >= X.Y\", or even\n> > \"include only when environment variable FOO is true\").\n> \n> It seems as though gitconfig doesn't have a standard way of dealing\n> with 'sub-subsections', which is essentially what this is trying to\n> implement.\n\nRight. Syntactically, the config keys are:\n\n SECTION.SUBSECTION.KEY\n\nwhere SUBSECTION is optional. SECTION and KEY cannot contain spaces or\ndots and are case insensitive, but SUBSECTION is handled literally. It\ncan contain whatever data is useful to the config parser (for example,\nremote names, branch names, or even URLs), including spaces or dots.\n\nWe could introduce the notion of sub-subsections, but that would not\nplay well with existing uses of subsection, which assume that they can\nput arbitrary data into it.\n\n> It makes sense that there could be different 'modes' of includes.\n> These could be the ones you mentioned already, such as repo and env,\n> but could also be things like branch where the config changes\n> depending on which branch you are on. Ideally, multiple entries per\n> mode would be allowed.\n>\n> Implementing all that initially would be overkill however if this sort\n> of functionality is desirable the ability to easily add new modes\n> would be a great boon down the track.\n\nRight. We don't have to decide on all of it now; we just have to leave\nthe door open syntactically for future growth.\n\n> The four pieces of information we need to include are that this is an\n> include, the path to the include, the mode, and the mode specific\n> parameter. Your proposal is to allow the sub-subsection by\n> concatenating with a \":\" like this\n> \n> [include \":]\n> path = \n\nRight. The config parser does not care about the sub-subsection; it is\nup to the interpreter of the key to split the subsection if it chooses.\nI arbitrarily chose \":\" as the internal delimiter because I thought it\nlooked nice. You could make it dot or space, too.\n\n> Alternatively, we could allow chaining of subsections (couldn't find\n> any previous discussion on this) by adding whitespace between each\n> subsection. Seems like lots of potentially unnecessary work, but maybe\n> this has already been discussed or is the most appropriate way of\n> doing it.\n> \n> $ git config --global include.repo./magic/.path ~/.gitconfig-magic\n> \n> [include repo \"/magic/\"]\n> path = .gitconfig-magic\n\nI don't think it has been discussed before. But as I mentioned above,\nyou would not want to apply this everywhere. For existing config\ncallbacks, they want to take the section literally. So it is going to be\nup to the callback to parse the section into subsections anyway, at\nwhich point it does not really matter what syntax you use.\n\nWe could teach the config parser to normalize:\n\n [section with many spaces]\n key\n\nas \"section.with.many.spaces.key\" or \"section.with many spaces.key\" (I\ndo not think it is even valid in today's code, but I didn't check). But\npersonally I do not find that any easier to read or understand than the\ncolon syntax.\n\n> This seems like the easiest and most flexible method, and doesn't\n> require any 'special' considerations for the subsection. It would be\n> harder for a user to configure, and the concept of a mode seems less\n> intuitive.\n> \n> $ git config --global include.magicrepos.mode repo\n> $ git config --global include.magicrepos.param /magic/\n> $ git config --global include.magicrepos.path ~/.gitconfig-magic\n> \n> [include \"magicrepos\"]\n> mode = repo\n> param = \"/magic/\"\n> path = ~/.gitconfig-magic\n\nYeah, that is the most flexible. You could introduce multiple conditions\nor other options, as well (e.g., instead of mode and param, have\ninclude.magic.repo, include.magic.env, etc). But it seems like\nover-engineering. I do not mind making the code a little harder to\nwrite, but it seems unnecessarily complicated for the user, too.\n\n> Of the three I probably think the subsection chaining is the nicest\n> overall, though your original \"repo:\" proposal seems to be the easiest\n> to implement.\n\nI think I favor the colon proposal because of its simplicity. And\nbecause the sub-section chaining cannot be applied consistently across\nconfig keys, I don't think there is much value in trying to introduce a\nnew general config syntax.\n\n-Peff\n"},{"id":"225149","messageId":"7vwqnpy2l4.fsf@alter.siamese.dyndns.org","threadId":"34661","inReplyTo":"20130812123921.GA16088@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-13T16:31:35Z","receivedAt":"2013-08-13T16:31:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> diff --git a/config.c b/config.c\n> index e13a7b6..a31dc85 100644\n> --- a/config.c\n> +++ b/config.c\n> @@ -119,10 +119,45 @@ int git_config_include(const char *var, const char *value, void *data)\n> \treturn ret;\n> }\n> \n> +static NORETURN void die_bad_regex(int err, regex_t *re)\n> +{\n> +\tchar errbuf[1024];\n> +\tregerror(err, re, errbuf, sizeof(errbuf));\n> +\tif (cf && cf->name)\n> +\t\tdie(\"bad regex (at %s:%d): %s\", cf->name, cf->linenr, errbuf);\n> +\telse\n> +\t\tdie(\"bad regex: %s\", errbuf);\n> +}\n> +\n> +static int match_repo_path(const char *re_str)\n> +{\n> +\tregex_t re;\n> +\tint ret;\n> +\tconst char *repo_path;\n> +\n> +\tret = regcomp(&re, re_str, REG_EXTENDED);\n> +\tif (ret)\n> +\t\tdie_bad_regex(ret, &re);\n> +\n> +\trepo_path = absolute_path(get_git_dir());\n> +\tret = regexec(&re, repo_path, 0, NULL, 0);\n> +\tregfree(&re);\n> +\treturn !ret;\n\nWe do this every time during the parsing?\n\nHmph, if you had \"include.repo:/home/junio/frotz/.path\" and\n\"include.repo:/srv/project/git.git/.path\" in your ~/.gitconfig,\nthen a single regexp that is lazily prepared once will not cut it,\nso I guess that you cannot avoid it.\n\nUnlike \"git init|clone --profile=foo\" that requires you to be\nexplicit about your profile upon invocation, this mechanism is much\neasier to use by having include..path in some global\nconfiguration, and the existing precedence rule makes it perfect.\nBy starting /etc/gitconfig and/or your $HOME/.gitconfig with series\nof include..path, you can have the default definitions\nincluded from these magic include to take effect before anything\nelse, and settings from other configuration files can override it.\n"},{"id":"225150","messageId":"7vsiydy2i1.fsf@alter.siamese.dyndns.org","threadId":"34661","inReplyTo":"20130813114635.GA16506@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-13T16:33:26Z","receivedAt":"2013-08-13T16:33:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I guess we could do something like:\n>\n> [include \"repo:...your regex here...\"]\n> path = .gitconfig-only-for-some-repos\n> [include \"env:USE_MY_MAGIC_CONFIG\"]\n> path = .gitconfig-only-when-magic-env-set\n\nI am not sure if \"env\" is very useful, but there certainly are other\npossibilities (e.g. apply this only on this host, only for members\nof this UNIX group, etc.), so having \"repo:\" prefix even if we only\nsupport the repository path mapping in the initial version is a good\nway forward.\n\nThanks.\n"},{"id":"225181","messageId":"520B2D11.2080405@alum.mit.edu","threadId":"34661","inReplyTo":"20130813114635.GA16506@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-08-14T07:09:05Z","receivedAt":"2013-08-14T07:09:05Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 08/13/2013 01:46 PM, Jeff King wrote:\n> On Tue, Aug 13, 2013 at 09:05:40PM +1000, Andrew Ardill wrote:\n> \n>> I applied this on top of latest next (1da3ebde8999d07), and it worked\n>> perfectly for my use case.\n>>\n>> For what it's worth, it also passed the test suite!\n>>\n>> Would be great to see this, or something on the same theme, get into\n>> master. I'd be happy to review patches/write tests/write documentation\n>> if needed.\n> \n> Like I said, I do not have a particular use for it, but I don't think it\n> would hurt anybody who does not use it. If you want to polish it up into\n> a real patch with docs and tests, I don't mind.\n> \n> The only downside I can think of is that we might want to use the\n> subsection in \"include.SUBSECTION.*\" for some other limiting conditions\n> (e.g., \"only include this config when running version >= X.Y\", or even\n> \"include only when environment variable FOO is true\").\n> \n> I guess we could do something like:\n> \n> [include \"repo:...your regex here...\"]\n> path = .gitconfig-only-for-some-repos\n> [include \"env:USE_MY_MAGIC_CONFIG\"]\n> path = .gitconfig-only-when-magic-env-set\n> \n> Adding the \"repo:\" prefix for this repo-dir matching is pretty trivial.\n> Adding a similar env-matching is only slightly less trivial; but does\n> anybody actually want it?\n\nGaaak! Let me again plead for supporting a post-clone hook rather than\ninventing some crazy config-file syntax that is becoming ever more\ncomplicated. A post-clone hook would make all of these things that have\nbeen suggested pretty easy, and would also open lots of other\npossibilities, all without further changes in git.core, like (I'm just\nbrainstorming here):\n\n #! /bin/sh\n\n remote=\"$1\"\n\n ln -s $(HOME)/.githooks/* .git/hooks\n\n case \"$(git --version)\" in\n *.1.[78].*)\n git config include.path \"$(HOME)/.gitinclude\n ;;\n esac\n\n echo \"(cd $(pwd) && git gc)\" >>\"$(HOME)/cron.weekly/git-gc\"\n\n case \"$remote\" in\n *.work.com/*)\n git config user.email me@work.com\n ;;\n *.github.com/*)\n git config user.email me@debian.org\n ;;\n *)\n echo '### Remember to set user.email ###'\n ;;\n esac\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"225185","messageId":"vpqsiycn33b.fsf@anie.imag.fr","threadId":"34661","inReplyTo":"7vsiydy2i1.fsf@alter.siamese.dyndns.org","subject":"Re: git should not use a default user.email config value","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-14T07:28:24Z","receivedAt":"2013-08-14T07:28:24Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> I guess we could do something like:\n>>\n>> [include \"repo:...your regex here...\"]\n>> path = .gitconfig-only-for-some-repos\n>> [include \"env:USE_MY_MAGIC_CONFIG\"]\n>> path = .gitconfig-only-when-magic-env-set\n>\n> I am not sure if \"env\" is very useful, but there certainly are other\n> possibilities (e.g. apply this only on this host, only for members\n> of this UNIX group, etc.)\n\nI have already wished I had \"git version >= XXX\" here (but that's tricky\nto implement).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"225186","messageId":"20130814073107.GA5095@sigill.intra.peff.net","threadId":"34661","inReplyTo":"520B2D11.2080405@alum.mit.edu","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-14T07:31:08Z","receivedAt":"2013-08-14T07:31:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 14, 2013 at 09:09:05AM +0200, Michael Haggerty wrote:\n\n> Gaaak! Let me again plead for supporting a post-clone hook rather than\n> inventing some crazy config-file syntax that is becoming ever more\n> complicated. A post-clone hook would make all of these things that have\n> been suggested pretty easy, and would also open lots of other\n> possibilities, all without further changes in git.core, like (I'm just\n> brainstorming here):\n\nMy problem with a post-clone hook is that it only runs once, and then\npotentially goes stale. For example:\n\n> ln -s $(HOME)/.githooks/* .git/hooks\n\nBecause of the symlink, this tracks hooks as they are updated, but what\nhappens when you add a new hook (or delete one)? You have to manually\nhunt down each repository using it and update the links. You can get it\naround it by replacing and symlinking the whole hook directory, though.\n\n> case \"$(git --version)\" in\n> *.1.[78].*)\n> git config include.path \"$(HOME)/.gitinclude\n> ;;\n> esac\n\nWhat happens when you upgrade (or downgrade) your git, or even use\nmultiple versions interleaved? You need to revisit this version check.\n\n> echo \"(cd $(pwd) && git gc)\" >>\"$(HOME)/cron.weekly/git-gc\"\n\nWhat happens when you move your repository to a different directory? You\nhave to manually fix up the generated cron script.\n\n> case \"$remote\" in\n> *.work.com/*)\n> git config user.email me@work.com\n> ;;\n> *.github.com/*)\n> git config user.email me@debian.org\n> ;;\n> *)\n> echo '### Remember to set user.email ###'\n> ;;\n> esac\n\nWhat happens when you update your address? You have to manually fix up\neach repository.\n\nI agree that running arbitrarily shell code is the most flexible thing,\nbut I think in many cases users would prefer to have something that\nmakes decisions at runtime, rather than having to remember to update\nexisting repositories with changes. That can be shell code, too, though\nthere are complications (performance and security come to mind).\n\nI do not see the two features as necessarily an either-or; they can\naccomplish the same thing, but with different tradeoffs in complexity\nfor the user.\n\n-Peff\n"},{"id":"225187","messageId":"20130814074035.GB5095@sigill.intra.peff.net","threadId":"34661","inReplyTo":"vpqsiycn33b.fsf@anie.imag.fr","subject":"Re: git should not use a default user.email config value","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-14T07:40:35Z","receivedAt":"2013-08-14T07:40:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 14, 2013 at 09:28:24AM +0200, Matthieu Moy wrote:\n\n> Junio C Hamano writes:\n> \n> > Jeff King writes:\n> >\n> >> I guess we could do something like:\n> >>\n> >> [include \"repo:...your regex here...\"]\n> >> path = .gitconfig-only-for-some-repos\n> >> [include \"env:USE_MY_MAGIC_CONFIG\"]\n> >> path = .gitconfig-only-when-magic-env-set\n> >\n> > I am not sure if \"env\" is very useful, but there certainly are other\n> > possibilities (e.g. apply this only on this host, only for members\n> > of this UNIX group, etc.)\n> \n> I have already wished I had \"git version >= XXX\" here (but that's tricky\n> to implement).\n\nI assume it is \"because version XXX understands config option Y, but\nolder versions do not\"[1]. Rather than ask for version XXX, then, you\ncould ask for\n\n [include \"option:Y\"]\n path = ...\n\nand versions which understand Y (which happens to be XXX or greater)\nwould internally know that and consider the conditional true.\n\nThis whole discussion is basically implementing conditional config. In\nmy patch, the conditional is limited only to including other config. But\nif you have many such conditions (and especially if each one only has\none varying config key), the result can be unwieldy. Another way of\ndoing this would be to introduce a conditional syntax to ignore or\nrespect some part of the file. The problem is that it would be tricky to\ndo in a backwards-compatible way.\n\n-Peff\n\n[1] I used to run into this with pager.*, which originally could only be\n a bool, but later learned to take custom pagers. I solved it with:\n\n git config --file .gitconfig-pager pager.diff ...\n git config --global include.path .gitconfig-pager\n\n which does not need a version or option conditional, because the\n option was added _before_ the include feature. IOW, older versions\n of git ignore it, and any which actually respect the include will\n know how to handle custom pagers. But that does not work with\n changes that came after the include feature was added. :)\n"},{"id":"225189","messageId":"vpq38qcmzw1.fsf@anie.imag.fr","threadId":"34661","inReplyTo":"20130814074035.GB5095@sigill.intra.peff.net","subject":"Re: git should not use a default user.email config value","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-14T08:37:34Z","receivedAt":"2013-08-14T08:37:34Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> This whole discussion is basically implementing conditional config.\n> [...] The problem is that it would be tricky to do in a\n> backwards-compatible way.\n\nThat could be done with \"conditional comments\" like\n\n# if then\n[core]\n pager = less\n# endif\n\nThat's rather ugly, and the implementation would be even more ugly, but\nbackward-compatible.\n\n> [1] I used to run into this with pager.*, which originally could only be\n> a bool, but later learned to take custom pagers. I solved it with:\n>\n> git config --file .gitconfig-pager pager.diff ...\n> git config --global include.path .gitconfig-pager\n\nSame here, with push.default = upstream, which breaks old versions of\nGit ;-).\n\n(I have a recent Git on my desktop, and my $HOME is shared with a server\nrunning Debian oldstable)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"225201","messageId":"CAPc5daWqzTkMFkecrAjMCmxwZZrgUtB-FVKrjsmfvpgwPgF8AA@mail.gmail.com","threadId":"34661","inReplyTo":"vpq38qcmzw1.fsf@anie.imag.fr","subject":"Re: git should not use a default user.email config value","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-14T14:00:58Z","receivedAt":"2013-08-14T14:00:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy\n wrote:\n>\n> Jeff King writes:\n>\n> > This whole discussion is basically implementing conditional config.\n> > [...] The problem is that it would be tricky to do in a\n> > backwards-compatible way.\n>\n> That could be done with \"conditional comments\" like\n>\n> # if then\n> [core]\n> pager = less\n> # endif\n>\n> That's rather ugly, and the implementation would be even more ugly, but\n> backward-compatible.\n\n\nI highly doubt that you would want to be \"backward compatible\" in this\ncase, though.\nThe section of the configuration you are enclosing the new if/endif\nsyntax may be\nunderstood only by newer Git (e.g. imagine core.pager is still\nbool-only today), and\nolder Git that do not understand if/endif syntax will happily read\nthat section and\nchoke on it, no?\n"},{"id":"225203","messageId":"vpqr4dwl61b.fsf@anie.imag.fr","threadId":"34661","inReplyTo":"CAPc5daWqzTkMFkecrAjMCmxwZZrgUtB-FVKrjsmfvpgwPgF8AA@mail.gmail.com","subject":"Re: git should not use a default user.email config value","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-14T14:07:44Z","receivedAt":"2013-08-14T14:07:44Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy\n> wrote:\n>>\n>> Jeff King writes:\n>>\n>> > This whole discussion is basically implementing conditional config.\n>> > [...] The problem is that it would be tricky to do in a\n>> > backwards-compatible way.\n>>\n>> That could be done with \"conditional comments\" like\n>>\n>> # if then\n>> [core]\n>> pager = less\n>> # endif\n>>\n>> That's rather ugly, and the implementation would be even more ugly, but\n>> backward-compatible.\n>\n>\n> I highly doubt that you would want to be \"backward compatible\" in this\n> case, though.\n> The section of the configuration you are enclosing the new if/endif\n> syntax may be\n> understood only by newer Git (e.g. imagine core.pager is still\n> bool-only today), and\n> older Git that do not understand if/endif syntax will happily read\n> that section and\n> choke on it, no?\n\nIndeed. That would be more\n\n# if then\n# [core]\n# pager = less\n# endif\n\nwhich is even more ugly ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"225202","messageId":"20130814140853.GA32605@sigill.intra.peff.net","threadId":"34661","inReplyTo":"CAPc5daWqzTkMFkecrAjMCmxwZZrgUtB-FVKrjsmfvpgwPgF8AA@mail.gmail.com","subject":"conditional config syntax","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-14T14:08:53Z","receivedAt":"2013-08-14T14:08:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[updated subject, as we are very far off the original topic]\n\nOn Wed, Aug 14, 2013 at 07:00:58AM -0700, Junio C Hamano wrote:\n\n> > > This whole discussion is basically implementing conditional config.\n> > > [...] The problem is that it would be tricky to do in a\n> > > backwards-compatible way.\n> >\n> > That could be done with \"conditional comments\" like\n> >\n> > # if then\n> > [core]\n> > pager = less\n> > # endif\n> >\n> > That's rather ugly, and the implementation would be even more ugly, but\n> > backward-compatible.\n> \n> I highly doubt that you would want to be \"backward compatible\" in this\n> case, though. The section of the configuration you are enclosing the\n> new if/endif syntax may be understood only by newer Git (e.g. imagine\n> core.pager is still bool-only today), and older Git that do not\n> understand if/endif syntax will happily read that section and choke on\n> it, no?\n\nI would think the ideal behavior would be for existing implementations\nto just not include the conditional section.\n\nIf we take the conditional by default in existing versions of git (i.e.,\nthe behavior of Matthieu's proposal), then any \"do this only if version\nX or greater\" conditional is going to be inconsistent (it will be true\nfor old versions, not true for versions which understand conditionals\nbut pre-date X, and then true again for the actual versions you want).\n\nLikewise, if we introduce some new non-backwards-compatible syntax that\nexisting Git chokes on, then you have created a new compatibility\nproblem. You cannot use older versions of git, which is the exact\nproblem a version conditional is trying to solve.\n\nThat is one of the reasons that include.path is designed as it is; old\nversions accept it and do nothing (unless you specifically ask for it as\na value). And likewise, include.*.path will do nothing for existing\nversions of git.\n\nOr hmm. Maybe that is what you mean by \"choke on it\". Choke on the\ninvalid config, not on the new syntax.\n\n-Peff\n"},{"id":"225206","messageId":"7v7gfouvor.fsf@alter.siamese.dyndns.org","threadId":"34661","inReplyTo":"20130814140853.GA32605@sigill.intra.peff.net","subject":"Re: conditional config syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-14T15:41:08Z","receivedAt":"2013-08-14T15:41:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Or hmm. Maybe that is what you mean by \"choke on it\". Choke on the\n> invalid config, not on the new syntax.\n\nYes ;-)\n"}]}