Nathan Neulinger [off-list ref] writes:
quoted
I wouldn't mind having a GIT_EMAIL envvar with the semantics you mean,
but can you say more about the use case? What's wrong with the usual
EMAIL environment variable?
EMAIL actually worked for this case for me, but there wasn't any
equivalent for author name, so the commits all look like
"sharedaccount <myuser@mydomain>".
I do not want to go into the discussion on the sanity/insanity of
using such a "shared account", but I am guessing that you already
have a concrete and workable mechanism in mind to allow you to set
these environment variables such as GIT_WEAKER_AUTHOR_NAME to
individual real users who share that account, and I further guess
that that is what you use to set EMAIL. Am I guessing right?
If so, wouldn't it be a better option to use that mechanism to set
separate $HOME (or XDG_CONFIG_HOME if you prefer) to these real
users who share the account, so that separate $HOME/.gitconfig files
can be used by them?
On 05/30/2014 02:48 PM, Junio C Hamano wrote:
Nathan Neulinger [off-list ref] writes:
quoted
quoted
I wouldn't mind having a GIT_EMAIL envvar with the semantics you mean,
but can you say more about the use case? What's wrong with the usual
EMAIL environment variable?
EMAIL actually worked for this case for me, but there wasn't any
equivalent for author name, so the commits all look like
"sharedaccount <myuser@mydomain>".
I do not want to go into the discussion on the sanity/insanity of
using such a "shared account", but I am guessing that you already
have a concrete and workable mechanism in mind to allow you to set
these environment variables such as GIT_WEAKER_AUTHOR_NAME to
individual real users who share that account, and I further guess
that that is what you use to set EMAIL. Am I guessing right?
Yes, the behavior currently is:
If I can figure out "who", I'll set the EMAIL/attributes based on that.
If not, it'll default to the "don't know" behavior that throws up the list
Ideally, I'd prefer the second option be:
Force user to specify --author if a good default can't be determined
But there doesn't appear to be a way to do that.
If so, wouldn't it be a better option to use that mechanism to set
separate $HOME (or XDG_CONFIG_HOME if you prefer) to these real
users who share the account, so that separate $HOME/.gitconfig files
can be used by them?
Not really, since there are lots of servers, and lots of application/service accounts. Where filesystem acl'ing can be
used reasonably, it is, making this moot, but it still boils down to example case of "I have a team of X people
maintaining Y different applications, each on their own dedicated account". I'd just like a good mechanism to set
defaults based on information other than what is in the home dir on the occasions that users log in directly to the app
account, as opposed to doing updates offline on their own systems/to central repo/etc.
-- Nathan
------------------------------------------------------------
Nathan Neulinger nneul@neulinger.org
Neulinger Consulting (573) 612-1412
On Fri, May 30, 2014 at 02:58:47PM -0500, Nathan Neulinger wrote:
Yes, the behavior currently is:
If I can figure out "who", I'll set the EMAIL/attributes based on that.
If not, it'll default to the "don't know" behavior that throws up the list
Ideally, I'd prefer the second option be:
Force user to specify --author if a good default can't be determined
But there doesn't appear to be a way to do that.
Yeah, I don't think there is a blessed way to tell git "I am explicitly
_not_ giving you an identity". You can set user.email to "bogus.(none)"
which git will think "oh, I tried to get the FQDN, but failed". However,
that is not a documented interface, and I would not be surprised if it
changes in the future.
The instructions you get:
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
are probably not helpful either (you do not want the user to run "git
config", as that would interfere with the other shared users).
quoted
If so, wouldn't it be a better option to use that mechanism to set
separate $HOME (or XDG_CONFIG_HOME if you prefer) to these real
users who share the account, so that separate $HOME/.gitconfig files
can be used by them?
Not really, since there are lots of servers, and lots of application/service
accounts. Where filesystem acl'ing can be used reasonably, it is, making
this moot, but it still boils down to example case of "I have a team of X
people maintaining Y different applications, each on their own dedicated
account". I'd just like a good mechanism to set defaults based on
information other than what is in the home dir on the occasions that users
log in directly to the app account, as opposed to doing updates offline on
their own systems/to central repo/etc.
But I think anything you could set up in the environment could be set up
in an on-the-fly $HOME. For example, instead of:
GIT_WEAK_AUTHOR_NAME=$name
GIT_WEAK_AUTHOR_EMAIL=$email
do:
HOME=$(mktemp -d gitenv.XXXXXX")
trap 'rm -rf "$HOME"' 0
git config --global user.name "$name"
git config --global user.email "$email"
You'd want to link in anything else you actually _want_ in $HOME, but
that also gives an opportunity to set up application-specific options
based on the user (e.g., if you could pull their .vimrc from some shared
storage or something).
-Peff