Re: [PATCH] tagger id

Junio C Hamano [off-list ref] writes:

ebiederm@xmission.com (Eric W. Biederman) writes:

quoted

Should this default to git_author_ident or git_committer_ident?
I'm not really certain how we expect to use the different flavors.

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.

Having said that, for something like this that would not be used
constantly and interatively by the users, my preference is not
to have any default at all, and always require --author or
--committer.  You have to type a bit more when doing the script,
but that needs to be done only once.  You will be sure which one
you are asking from the command two weeks after you wrote the
script so it is not a big loss.

Make sense.  Although I'm not quite certain we actually need the
information twice.  Possibly we just have GIT_AUTHOR_NAME and
GIT_AUTHOR_EMAIL, and then have commit-write take a flag to
override the author bit.  That would certainly make it less
confusing when setting up environmental variables for git.
And that would also give us a better name.

I am not seriously suggesting the below as an alternative, but
have you thought about doing an inverse function of your
computation for the case when the user has all the environment
variables, and have script eval its output, like this [*1*]:

    $ git-id
    GIT_AUTHOR_NAME='Junio C Hamano'
    GIT_AUTHOR_EMAIL='junkio@cox.net'
    GIT_COMMITTER_NAME='Junio C Hamano'
    GIT_COMMITTER_EMAIL='junkio@cox.net'
    $ eval "`git-id`"
    $ tagger="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"

Having names and emails available separately may turn out to be
easier to use in other situation.  Just a thought.

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).

By the way, I do not particularly like the name "git-id".  There
could be IDs for different kinds (not just people) we would want
later (file IDs, for example).  Naming what you are computing
_the_ "id" feels a bit too generic.  I do not have a better
alternative to suggest, though.

Agreed.  Something like git-author or git-author-stamp is probably
better.

*1* This makes its output syntax a bit too specific to the shell
and unfriendly to Porcelain written in other languages.  The
only non-shell Porcelains I am aware of are done in Perl (I do
not remember hearing its name) and Python (StGIT), both of which
have reasonable regexp support to grok something like this, so
it would not be a big issue.

And in git-commit-script this is actually parsed by sed which makes
it so the shell can parse the information as well so I think
we are fine in that sense.

Eric