Eric W. Biederman <ebiederm <at> xmission.com> writes:
> Junio C Hamano <junkio <at> 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?
$ git-env [--values-only] [<variable name>...]
$ git-env GIT_COMMITER_DATE GIT_AUTHOR_NAME
GIT_AUTHOR_NAME='Junio C Hamano'
$ unset GIT_OBJECT_DIRECTORY
$ GIT_DIR=foo git-env --values-only GIT_OBJECT_DIRECTORY
$ 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 <[EMAIL PROTECTED]> 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..
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html