feature request: allow commit.email config setting

As part of my dayjob, I did and still do some work on an upstream project. A while ago, I was granted commit access to that project. However, upstream asked that I would register with their system using a private email, or at least one that wouldn't change if I changed jobs, rather than my work email.

Now, I (and my employer) would like that the work I do as part of my current job on that project has my work email in the Author field, but since the commit access was granted to me privately/personally, it would be nice if the Committer email was the one I used to register with their system. I can set GIT_COMMITTER_EMAIL in the environment, but that is rather inconvenient, since that means I have to remember to do that in the shell I'm using for that particular project, and I can't use that shell for other projects. So it would be really nice if I could set commit.email = $private-email in the local .git/config for that particular project. I don't personally have a use for commit.name (when missing, that should just use user.name as usual), but it would probably be most consistent to allow that too.

I tried looking into ident.c, but it doesn't seem like it is straight-forward to implement. Probably fmt_ident, ident_default_email etc. would need to be passed information about what purpose the ident is to be used for. So before trying to implement this, I want to hear if this is a reasonable thing to support. Also, I'm sure there are some subtle semantics that would need to be decided and gotchas to watch out for.

Rasmus

Rasmus Villemoes <rv@rasmusvillemoes.dk> writes:

We only have user.email and user.name because nobody in the past 10+ years had such a requirement, but I find it it a perfectly sensible thing to wish to say "tagger.email and tagger.name are used while creating an annotated tag, committer.email and committer.name are used on the 'committer' line and author.email and author.name are used on the 'author' line in a newly created commit; by the way, if any of these are not set, but user.email or user.name is set, then they are used as fallback values." at the design level.

On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:

Aside from modifying Git itself to support such a use-case, another (perhaps more pragmatic) approach would be to use a tool, such as direnv[1], which automatically sets environment variables for you depending upon your current working directory, or just use some ad-hoc shell programming to achieve the same (for instance, [2]).

[1]: https://direnv.net [2]: https://stackoverflow.com/questions/14462591/set-environmental-variables-in-a-particular-directory

On 2018-08-30 20:13, Eric Sunshine wrote:

Thanks for the hint! I've actually had "git" as a function in my .bashrc for a long time, for implementing a ~/.githistory to help remember the sometimes rather complex git invocations, and keeping track of the context ($cwd, current branch, etc.) they were used in. It should be trivial to hook the environment settings based on $cwd into that. The only problem is that that gives me much less incentive to work on implementing the config support in git, but if I'm the only one with a use case, that's probably just as well.

Rasmus