{"thread":{"id":"36793","subject":"feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","startedAt":"2014-05-30T18:19:17Z","lastAt":"2014-06-02T06:59:51Z","messageCount":8,"participants":["Nathan Neulinger","Jonathan Nieder","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"243030","messageId":"5388CBA5.9030403@neulinger.org","threadId":"36793","inReplyTo":null,"subject":"feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","fromName":"Nathan Neulinger","fromEmail":"nneul@neulinger.org","sentAt":"2014-05-30T18:19:17Z","receivedAt":"2014-05-30T18:19:17Z","isPatch":false,"sender":{"key":"nneul@neulinger.org","avatar":"https://gravatar.com/avatar/6bf7d938addba77b29fe46572be573fd52d1e4dbea47218c4397d760c87aabd1?d=mp&s=160"},"body":"Four related feature requests/ideas:\n\n\n1. equivalent to GIT_*_EMAIL/NAME vars, but processed only if git config doesn't set values\n\nRight now, there isn't any way to have a systemwide profile script that tries to determine a better default for the user \nname/email values, such as in the case of shared logins. The best I've been able to do for now is use the 'EMAIL' var.\n\nUse case in my environment - most shared-login accounts are accessed via krb5 login, so it provides a nice way to set a \nbetter default for \"who is doing this commit\" than just the userid.\n\n\n2. Setting option to user.name (or other setting) that would BLOCK the commit from occurring at all if it would \notherwise fall back to defaults. I thought this previously worked by setting an empty value, but apparently doesn't work \nthat way in current versions.\n\n\n3. Setting option to user.name/user.email to prompt, SVN-style, for the name/email. Yes, this would be \nannoying/obnoxious to use normally, but intent is to avoid un-named \"root@host\" commits that would otherwise occur from \nuser being lazy.\n\n\n4. (This would accomplish all of the above) - enhance the include.path option to support the \"!\" syntax similar to what \naliases can do. i.e.\n\n[include]\n    path = !/usr/local/bin/gen-git-env\n\nor\n\n[include]\n    cmd = /usr/local/bin/gen-git-env\n\n\n-- Nathan\n\n------------------------------------------------------------\nNathan Neulinger                       nneul@neulinger.org\nNeulinger Consulting                   (573) 612-1412\n"},{"id":"243031","messageId":"20140530182746.GK12314@google.com","threadId":"36793","inReplyTo":"5388CBA5.9030403@neulinger.org","subject":"Re: feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-05-30T18:27:46Z","receivedAt":"2014-05-30T18:27:46Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nNathan Neulinger wrote:\n\n> Right now, there isn't any way to have a systemwide profile script\n> that tries to determine a better default for the user name/email\n> values, such as in the case of shared logins. The best I've been\n> able to do for now is use the 'EMAIL' var.\n\nI wouldn't mind having a GIT_EMAIL envvar with the semantics you mean,\nbut can you say more about the use case?  What's wrong with the usual\nEMAIL environment variable?\n\n[...]\n> [include]\n>    path = !/usr/local/bin/gen-git-env\n\nThis is scary in terms of privilege escalation attacks.  (\"Admin,\ncould you please take a look at this repo?  When I run 'git status',\n...\".)\n\nThat said, smudge/clean filters may have the same problem already.\n\nThanks,\nJonathan\n"},{"id":"243036","messageId":"5388D175.3060500@neulinger.org","threadId":"36793","inReplyTo":"20140530182746.GK12314@google.com","subject":"Re: feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","fromName":"Nathan Neulinger","fromEmail":"nneul@neulinger.org","sentAt":"2014-05-30T18:44:05Z","receivedAt":"2014-05-30T18:44:05Z","isPatch":false,"sender":{"key":"nneul@neulinger.org","avatar":"https://gravatar.com/avatar/6bf7d938addba77b29fe46572be573fd52d1e4dbea47218c4397d760c87aabd1?d=mp&s=160"},"body":"> I wouldn't mind having a GIT_EMAIL envvar with the semantics you mean,\n> but can you say more about the use case?  What's wrong with the usual\n> EMAIL environment variable?\n\nEMAIL actually worked for this case for me, but there wasn't any equivalent for author name, so the commits all look \nlike \"sharedaccount <myuser@mydomain>\".\n\n> [...]\n>> [include]\n>>     path = !/usr/local/bin/gen-git-env\n>\n> This is scary in terms of privilege escalation attacks.  (\"Admin,\n> could you please take a look at this repo?  When I run 'git status',\n> ...\".)\n\nWouldn't that be pulling from ~sharedaccount/.gitconfig anyway though? (Agreed that it could be an issue if you have \nshared ssh agent, krb5 tgts, etc. - but that would exist any time you connected into a shared account.)\n\nI would probably take the approach of not supporting that syntax in anything other than the per-user gitconfig file \nthough as a safety measure - per-repo config could indeed be a problem.\n\n-- Nathan\n\n------------------------------------------------------------\nNathan Neulinger                       nneul@neulinger.org\nNeulinger Consulting                   (573) 612-1412\n"},{"id":"243041","messageId":"xmqqvbsn82u6.fsf@gitster.dls.corp.google.com","threadId":"36793","inReplyTo":"5388D175.3060500@neulinger.org","subject":"Re: feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-30T19:48:49Z","receivedAt":"2014-05-30T19:48:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nathan Neulinger <nneul@neulinger.org> writes:\n\n>> I wouldn't mind having a GIT_EMAIL envvar with the semantics you mean,\n>> but can you say more about the use case?  What's wrong with the usual\n>> EMAIL environment variable?\n>\n> EMAIL actually worked for this case for me, but there wasn't any\n> equivalent for author name, so the commits all look like\n> \"sharedaccount <myuser@mydomain>\".\n\nI do not want to go into the discussion on the sanity/insanity of\nusing such a \"shared account\", but I am guessing that you already\nhave a concrete and workable mechanism in mind to allow you to set\nthese environment variables such as GIT_WEAKER_AUTHOR_NAME to\nindividual real users who share that account, and I further guess\nthat that is what you use to set EMAIL.  Am I guessing right?\n\nIf so, wouldn't it be a better option to use that mechanism to set\nseparate $HOME (or XDG_CONFIG_HOME if you prefer) to these real\nusers who share the account, so that separate $HOME/.gitconfig files\ncan be used by them?\n"},{"id":"243043","messageId":"5388E2F7.606@neulinger.org","threadId":"36793","inReplyTo":"xmqqvbsn82u6.fsf@gitster.dls.corp.google.com","subject":"Re: feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","fromName":"Nathan Neulinger","fromEmail":"nneul@neulinger.org","sentAt":"2014-05-30T19:58:47Z","receivedAt":"2014-05-30T19:58:47Z","isPatch":false,"sender":{"key":"nneul@neulinger.org","avatar":"https://gravatar.com/avatar/6bf7d938addba77b29fe46572be573fd52d1e4dbea47218c4397d760c87aabd1?d=mp&s=160"},"body":"\n\nOn 05/30/2014 02:48 PM, Junio C Hamano wrote:\n> Nathan Neulinger <nneul@neulinger.org> writes:\n>\n>>> I wouldn't mind having a GIT_EMAIL envvar with the semantics you mean,\n>>> but can you say more about the use case?  What's wrong with the usual\n>>> EMAIL environment variable?\n>>\n>> EMAIL actually worked for this case for me, but there wasn't any\n>> equivalent for author name, so the commits all look like\n>> \"sharedaccount <myuser@mydomain>\".\n>\n> I do not want to go into the discussion on the sanity/insanity of\n> using such a \"shared account\", but I am guessing that you already\n> have a concrete and workable mechanism in mind to allow you to set\n> these environment variables such as GIT_WEAKER_AUTHOR_NAME to\n> individual real users who share that account, and I further guess\n> that that is what you use to set EMAIL.  Am I guessing right?\n\nYes, the behavior currently is:\n\n\tIf I can figure out \"who\", I'll set the EMAIL/attributes based on that.\n\tIf not, it'll default to the \"don't know\" behavior that throws up the list\n\nIdeally, I'd prefer the second option be:\n\n\tForce user to specify --author if a good default can't be determined\n\nBut there doesn't appear to be a way to do that.\n\n> If so, wouldn't it be a better option to use that mechanism to set\n> separate $HOME (or XDG_CONFIG_HOME if you prefer) to these real\n> users who share the account, so that separate $HOME/.gitconfig files\n> can be used by them?\n\nNot really, since there are lots of servers, and lots of application/service accounts. Where filesystem acl'ing can be \nused reasonably, it is, making this moot, but it still boils down to example case of \"I have a team of X people \nmaintaining Y different applications, each on their own dedicated account\". I'd just like a good mechanism to set \ndefaults based on information other than what is in the home dir on the occasions that users log in directly to the app \naccount, as opposed to doing updates offline on their own systems/to central repo/etc.\n\n-- Nathan\n\n------------------------------------------------------------\nNathan Neulinger                       nneul@neulinger.org\nNeulinger Consulting                   (573) 612-1412\n"},{"id":"243045","messageId":"20140530200945.GB5513@sigill.intra.peff.net","threadId":"36793","inReplyTo":"5388E2F7.606@neulinger.org","subject":"Re: feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-30T20:09:45Z","receivedAt":"2014-05-30T20:09:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 30, 2014 at 02:58:47PM -0500, Nathan Neulinger wrote:\n\n> Yes, the behavior currently is:\n> \n> \tIf I can figure out \"who\", I'll set the EMAIL/attributes based on that.\n> \tIf not, it'll default to the \"don't know\" behavior that throws up the list\n> \n> Ideally, I'd prefer the second option be:\n> \n> \tForce user to specify --author if a good default can't be determined\n> \n> But there doesn't appear to be a way to do that.\n\nYeah, I don't think there is a blessed way to tell git \"I am explicitly\n_not_ giving you an identity\". You can set user.email to \"bogus.(none)\"\nwhich git will think \"oh, I tried to get the FQDN, but failed\". However,\nthat is not a documented interface, and I would not be surprised if it\nchanges in the future.\n\nThe instructions you get:\n\n\t*** Please tell me who you are.\n\t\n\tRun\n\t\n\t  git config --global user.email \"you@example.com\"\n\t  git config --global user.name \"Your Name\"\n\t\n\tto set your account's default identity.\n\tOmit --global to set the identity only in this repository.\n\t\n\nare probably not helpful either (you do not want the user to run \"git\nconfig\", as that would interfere with the other shared users).\n\n> >If so, wouldn't it be a better option to use that mechanism to set\n> >separate $HOME (or XDG_CONFIG_HOME if you prefer) to these real\n> >users who share the account, so that separate $HOME/.gitconfig files\n> >can be used by them?\n> \n> Not really, since there are lots of servers, and lots of application/service\n> accounts. Where filesystem acl'ing can be used reasonably, it is, making\n> this moot, but it still boils down to example case of \"I have a team of X\n> people maintaining Y different applications, each on their own dedicated\n> account\". I'd just like a good mechanism to set defaults based on\n> information other than what is in the home dir on the occasions that users\n> log in directly to the app account, as opposed to doing updates offline on\n> their own systems/to central repo/etc.\n\nBut I think anything you could set up in the environment could be set up\nin an on-the-fly $HOME. For example, instead of:\n\n  GIT_WEAK_AUTHOR_NAME=$name\n  GIT_WEAK_AUTHOR_EMAIL=$email\n\ndo:\n\n  HOME=$(mktemp -d gitenv.XXXXXX\")\n  trap 'rm -rf \"$HOME\"' 0\n  git config --global user.name \"$name\"\n  git config --global user.email \"$email\"\n\nYou'd want to link in anything else you actually _want_ in $HOME, but\nthat also gives an opportunity to set up application-specific options\nbased on the user (e.g., if you could pull their .vimrc from some shared\nstorage or something).\n\n-Peff\n"},{"id":"243058","messageId":"xmqq1tvb7xw6.fsf@gitster.dls.corp.google.com","threadId":"36793","inReplyTo":"20140530200945.GB5513@sigill.intra.peff.net","subject":"Re: feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-30T21:35:37Z","receivedAt":"2014-05-30T21:35:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, May 30, 2014 at 02:58:47PM -0500, Nathan Neulinger wrote:\n>\n>> Not really, since there are lots of servers,...\n>\n> But I think anything you could set up in the environment could be set up\n> in an on-the-fly $HOME. For example, instead of:\n>\n>   GIT_WEAK_AUTHOR_NAME=$name\n>   GIT_WEAK_AUTHOR_EMAIL=$email\n>\n> do:\n>\n>   HOME=$(mktemp -d gitenv.XXXXXX\")\n>   trap 'rm -rf \"$HOME\"' 0\n>   git config --global user.name \"$name\"\n>   git config --global user.email \"$email\"\n>\n> You'd want to link in anything else you actually _want_ in $HOME, but\n> that also gives an opportunity to set up application-specific options\n> based on the user (e.g., if you could pull their .vimrc from some shared\n> storage or something).\n\nYes.  I agree that \"Not really, ...\" was not very convincing to me.\n\nAnother thing that might be useful in general (i.e. I am not\nparticularly trying to help the \"shared\" configuration on the topic\nof this thread) is to allow environment variable substitution in\nexpand_user_path().\n\nNathan's installation can set a \"GIT_MYSELF\" and then have something\nlike this in the shared $HOME/.gitconfig\n\n\t[include]\n        \tpath = /usr/local/users/$GIT_MYSELF/ident\n\nwe could even make the whole thing fail when GIT_MYSELF is not set\nbut I haven't thought things through ;-)\n"},{"id":"243122","messageId":"20140602065947.GC27254@sigill.intra.peff.net","threadId":"36793","inReplyTo":"xmqq1tvb7xw6.fsf@gitster.dls.corp.google.com","subject":"Re: feature request - implement a \"GIT_AUTHOR_EMAIL\" equivalent, but processed BEFORE .gitconfig","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-06-02T06:59:51Z","receivedAt":"2014-06-02T06:59:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 30, 2014 at 02:35:37PM -0700, Junio C Hamano wrote:\n\n> Nathan's installation can set a \"GIT_MYSELF\" and then have something\n> like this in the shared $HOME/.gitconfig\n> \n> \t[include]\n>         \tpath = /usr/local/users/$GIT_MYSELF/ident\n> \n> we could even make the whole thing fail when GIT_MYSELF is not set\n> but I haven't thought things through ;-)\n\nYeah, that is something I considered[1] when writing the initial\ninclude.path implementation. Something like:\n\n  [include]\n\tpath = .gitconfig-$HOSTNAME\n\ncould be potentially useful. But I punted at the time to wait for\nsomebody to actually ask for it. If somebody wanted to implement it, I\ndon't see a reason to avoid it.\n\n-Peff\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/190196\n"}]}