From: Eric W. Biederman <ebiederm@xmission.com>
Date: Fri, 15 Jul 2005 00:46:16 GMT
Subject: Re: [PATCH] tagger id
Message-ID: <m1zmsoyjzb.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <loom.20050712T230013-978@post.gmane.org>

Junio C Hamano <junkio@twinsun.com> writes:

> Eric W. Biederman <ebiederm <at> xmission.com> writes:
>
>
>> 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?

I like the general idea.  But I hate the code implications for
echoing environmental variables that git cares about.  Especially
since we really don't care about the environmental variables.  Instead
we are doing this because we are doing things that the are best
not done in shell.

So I have made the program git-var [ -l | <variable name ]

Without the implicit tying we can just export those values
that we find interesting. -l will list all of the variables
and their values like env, while specifying an single variable
will just read that variables value.

Eric