Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

[Jeff King <peff@peff.net>]

On Fri, Jul 29, 2016 at 10:47:27AM -0700, Junio C Hamano wrote:

> > In those cases specifically, I never have local commits that differ
> > from the remote, so a "pull --ff-only" should leave me in the same
> > state as a "pull --rebase".
> >
> > Is this a case of rebase trying to make sure it has enough information
> > for me to be a committer before knowing whether I even need to rewrite
> > any commits, and could/should that be avoided?  Alternatively (or also)
> > could/should rebase detect that a fast-forward is possible and prefer
> > to do that instead?
> 
> I think that is a reasonable argument, but to solve this for a more
> general case, shouldn't we be discussing a solution that would also
> work when rebase _does_ need to create a new commit?  And when the
> latter is solved, I would imagine that "this rebase happens to be
> fast-forward, and not having an ident shouldn't be an issue for this
> special case" would become moot.

Wouldn't it be wrong to create a commit with non-config ident when
user.useConfigOnly is set, though? That is the exact point when it
should kick in, to tell the user "you thought it would not matter here,
but in this case we _do_ need your real ident; what should we do?"

If the user is doing a one-off thing where they do not care if their
crappy, fake ident makes it into a commit object, then the right thing
is:

  git -c user.useConfigOnly=false pull --rebase

or even:

  git -c user.email=fake-but-ok@example.com pull --rebase

And they can do that preemptively for commands like the golang example
here. They shouldn't _have_ to do that, though, if the command wouldn't
actually create a commit. So I do think there may be a bug to be fixed,
but it is simply commands being over-eager to make sure we have an
ident when they might not need it.

-Peff