Eric W. Biederman <ebiederm <at> xmission.com> writes: > Since we are still looking at this there is one change in the user > interface I would like to make to simplify things for the end user. > The only time when GIT_COMMITTER != GIT_AUTHOR is in git_commit_script > when we you are making a new commit based on an old commit...
I am afraid I do not follow you. For a "project lead" person like Linus, who takes an e-mail submission of patches, GIT_AUTHOR is almost always different from the committer, and typically set up by the program that reads the e-mail to snarf the From: and Date: lines via environment variables, when the incoming patches are being processed. He is saying "I am the COMMITTER, and this commit I am making is written by this AUTHOR". AUTHOR can be set to somebody other than yourself and that is a typical mode of operation for a "project lead" person. On the other hand, we made COMMITTER overridable only because (1) the computed value from the system are often not quite right on many systems with weird GECOS field or domain/e-mail setup, and (2) when converting from a foreign SCM, we wanted to keep the committer information (and dates), if available. Only in (2), which is quite a special case, COMMITTER names somebody different from yourself. What this means is that if you are asking the question "who the user is", the answer _should_ always come from COMMITTER. > That also simplifies the tagging case and answers the question > which environment variables tags should look at, to see who the > user is. The intent of "tags" (especially the signed kind) is to express "trust": "This commit is called v2.6.12 and *I* vouch for it." COMMITTER is the only sensible thing to use there, because (as you said) what you care is "who I am", not "for whom I am doing this". - 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
