Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH v2] Introduce new configuation option to override committer information

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:26

Thomas Rast [off-list ref] writes:
Well, now that I'm rethinking it, the weird thing is that it does not
override in the way that the user intuitively might expect.

Assume we also had user.authoremail for completeness, and you do

  git config --global user.authoremail author@example.com
  git config --global user.committeremail committer@example.com
  git config user.email user@example.com

Probably the user would expect this to result in a uniform
user@example.com identity for the current repo, but I don't think we
can twist it that way with the current config infrastructure.  The
obvious option of having user.{author,committer}* override the more
generic user.* would be contrary to that intuition.
The thing is that the "intuition" is not so cut-and-dried.  "email" is
indeed more generic than "authoremail", so it is intuitive for the latter
to override the former.  But "$HOME/.gitconfig" is fallback default for
the repository specific .git/config so it also is intuitive for anything
in the latter to override whatever is in the former.  Now you have a
conflicting "more specific authoremail in more generic $HOME/.gitconfig vs
more generic email in more specific .git/config---which wins?" situation.

Is there a way to document the rule of precedence clearly?  For this
particular case, recommending against setting author/committer-email in
the fallback default $HOME/.gitconfig in the Documentation/config.txt
might be sufficient.

But I am still not convinced why two need to be custom-set differently
when both need to name _you_.  After all, Author and Committer are both
identifiers taken from the same namespace to identify real people, so if
you want to use one value for the committer to name _you_, I don't see a
sane reason why you want a different name to name the same _you_ in the
author field.

The specific use case in the thread talks about KDE workflow interpreting
the committer identifier in a particular way as a reason for it to be set
to a particular value, but does not clarify why the author has to be
different from that particular value for the committer.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help