From: Junio C Hamano Date: Tue, 12 Jul 2005 21:16:52 GMT Subject: Re: [PATCH] tagger id Message-ID: In-Reply-To: Eric W. Biederman xmission.com> writes: > > Junio C Hamano cox.net> writes: > > > The only in-tree user after your patch is applied is the tagger > > stuff, so in that sense committer_ident may make more sense. > > There is also the commit path, and that comes from C. I'm not > quite certain how we should be using the environmental variables. But there you would not have "default" issue, would you? > Part of the request was to put all of this information together > in a common place. And note that it is actually: > tagger="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE" > Where the date is a human unreadable string of the number of seconds > since the epoch (aka 1 Jan 1970 UTC). This may sound whacy, but how about having git-env command that (1) parrots GIT_* environment variables if the user has one; or (2) shows the values of environment variables the user _could_ have had to cause the program to behave the same way, when it the user does not have them? Synopsis. $ git-env [--values-only] [...] Examples. $ git-env GIT_COMMITER_DATE GIT_AUTHOR_NAME GIT_COMMITTER_DATE='1121202267 -0700' GIT_AUTHOR_NAME='Junio C Hamano' $ unset GIT_OBJECT_DIRECTORY $ GIT_DIR=foo git-env --values-only GIT_OBJECT_DIRECTORY foo/objects $ git-env GIT_DIR=.git GIT_OBJECT_DIRECTORY=.git/objects ... $ eval "`git-env GIT_COMMITTER_DATE GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE`" $ tagger="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE" We could add a couple of "variable name"s that we do _not_ use from the environment as a shorthand as well while we are at it, so that you can say: $ git-env GIT_COMMITTER_ID GIT_COMMITTER_ID='Junio C Hamano 1121202267 -0700' Once we go this route, it may even make sense to have that GIT_COMMITTER_ID environment variable as well. I don't know..