[EMAIL PROTECTED] (Eric W. Biederman) writes:
> 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.
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.
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='[EMAIL PROTECTED]'
GIT_COMMITTER_NAME='Junio C Hamano'
GIT_COMMITTER_EMAIL='[EMAIL PROTECTED]'
$ 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.
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.
[Footnote]
*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.
-
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
