Junio C Hamano <[EMAIL PROTECTED]> 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 - 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
