From: Junio C Hamano <junkio@cox.net>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: git@vger.kernel.org
Subject: Re: [PATCH] tagger id
Date: Tue, 12 Jul 2005 01:44:15 -0700 [thread overview]
Message-ID: <7veka48lcw.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <m18y0c1prv.fsf@ebiederm.dsl.xmission.com> (Eric W. Biederman's message of "Tue, 12 Jul 2005 00:50:44 -0600")
ebiederm@xmission.com (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='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.
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.
next prev parent reply other threads:[~2005-07-12 8:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-11 1:18 Trial git RPM's Linus Torvalds
2005-07-11 15:24 ` Eric W. Biederman
2005-07-11 17:06 ` Linus Torvalds
2005-07-11 20:11 ` Horst von Brand
2005-07-11 21:03 ` Chris Wright
2005-07-12 15:59 ` Eric W. Biederman
2005-07-12 17:01 ` Linus Torvalds
2005-07-12 17:14 ` Eric W. Biederman
2005-07-12 17:27 ` Linus Torvalds
2005-07-12 17:46 ` Chris Wright
2005-07-12 0:55 ` Eric W. Biederman
2005-07-12 1:15 ` Linus Torvalds
2005-07-12 2:39 ` Eric W. Biederman
2005-07-12 4:39 ` [PATCH] tagger id Eric W. Biederman
2005-07-12 6:50 ` Eric W. Biederman
2005-07-12 8:44 ` Junio C Hamano [this message]
2005-07-12 15:04 ` Eric W. Biederman
2005-07-12 15:14 ` Petr Baudis
2005-07-12 21:16 ` Junio C Hamano
2005-07-15 0:46 ` Eric W. Biederman
2005-07-12 18:54 ` Linus Torvalds
2005-07-12 22:15 ` Eric W. Biederman
2005-07-12 23:42 ` Junio C Hamano
2005-07-15 0:36 ` Eric W. Biederman
2005-07-12 0:58 ` Trial git RPM's Eric W. Biederman
2005-07-11 20:34 ` Chris Wright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7veka48lcw.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=ebiederm@xmission.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).