From: Duy Nguyen Date: Wed, 03 Feb 2016 05:26:36 GMT Subject: Re: [PATCH] Trick to force setup of a specific configured E-Mail per repo Message-ID: In-Reply-To: <20160203052209.GA22336@sigill.intra.peff.net> On Wed, Feb 3, 2016 at 12:22 PM, Jeff King wrote: > On Wed, Feb 03, 2016 at 12:19:20PM +0700, Duy Nguyen wrote: > >> On Wed, Feb 3, 2016 at 10:56 AM, Jeff King wrote: >> > I find it disappointing that we go back to looking for magic sequences >> > in the string. Could we perhaps do this more cleanly with a new config >> > option? Like a "user.guessIdent" which defaults to true, but people can >> > set to false. And without that, we do not do any automagic at all; we >> > get the values from the GIT_COMMITTER_* environment or the >> > user.{name,email} config variables, or we die(). >> > >> > I think that should allow your use case (and extend the same feature to >> > user.name). It wouldn't work on older versions of git, but nor would >> > your fix here (the only way to do that is to re-instate "(none)" as >> > magical). >> >> Should we generalize this use case, i.e. define a list of >> configuration variables that must be (re-)defined per-repo? Maybe not >> worth it, I don't know. I can't think of any other variable that >> should behave this way off the top of my head. > > That's an interesting thought, but I'm not sure how it would work. The > ident variables are special in that people are often unhappy with the > fallback. What would it mean for somebody to say "do not proceed if > diff.renameLimit is not set", and where would we enforce that? Enforcing it at git-init and git-clone, interactively asking the values of these variables, may be too much. If only we can catch if a variable is used, then we probably can catch it there. But that may require some more changes in config api. -- Duy