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@xxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html