feature request: allow commit.email config setting

feature request: allow commit.email config setting

[Rasmus Villemoes]

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

Re: feature request: allow commit.email config setting

[Junio C Hamano]

Rasmus Villemoes <rv@rasmusvillemoes.dk> writes:

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

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.

Re: feature request: allow commit.email config setting

[Eric Sunshine]

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

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

Re: feature request: allow commit.email config setting

[Rasmus Villemoes]

On 2018-08-30 20:13, Eric Sunshine wrote:
> On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
>> 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.
> 
> 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]).

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