Jeff King <peff@xxxxxxxx> writes: >> > 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 exactly what I was getting at. > 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 Hmm, I somehow had an impression that these git commands are not what the end-user runs from the command line, but wrapper tools like "go get" has a hardcoded invocation of "git pull". If a user sets useconfigonly globally, each repository must have ident the user wants to use in it configured, so I would think that a solution should be something that makes it easy to do so. -- 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