Jeff King [off-list ref] writes:
quoted
quoted
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@example.com 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.
On Fri, Jul 29, 2016 at 11:32:40AM -0700, Junio C Hamano wrote:
quoted
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.
Ah, OK, I thought you were trying to explore the opposite direction.
quoted
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
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".
Yeah, the right person or entity to set those options is the one who
knows "the operation I am doing is OK even with bogus ident". I had
assumed if "go get" fell under that category, that it should be the one
to tell it to git (via the config above).
But I am not really sure that is the case. In general "go get" shouldn't
make commits if you aren't doing active work on the repo (AFAIK), and it
should just work.
From my limited testing, "git pull --rebase" is perfectly fine. The
culprit is "--rebase=preverse", which complains even if it would be a
fast-forward.
-Peff
On Fri, Jul 29, 2016 at 02:39:11PM -0400, Jeff King wrote:
From my limited testing, "git pull --rebase" is perfectly fine. The
culprit is "--rebase=preverse", which complains even if it would be a
fast-forward.
That should be preserve, of course. :)
And I think I see what is happening. "preserve" implies
interactive-rebase, which makes an early check that we have valid
committer info, even though we might not actually write any new commits.
So doing this:
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index ded4595..f0f4777 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1180,9 +1180,6 @@ To continue rebase after editing, run:
;;
esac
-git var GIT_COMMITTER_IDENT >/dev/null ||
- die "$(gettext "You need to set your committer info first")"
-
comment_for_reflog start
if test ! -z "$switch_to"
fixes it for me. I can't figure out if that would have any bad side
effects, though. That check comes from Dscho's original 1b1dce4 (Teach
rebase an interactive mode, 2007-06-25), so there's not much comment on
why it was added specifically.
We would notice the bogus ident later when we actually do try to create
a commit object, but I can guess that this up-front check might give us
a better error message. You get warned up-front, rather than something
like:
Rebasing (1/1)
*** Please tell me who you are.
[...]
fatal: no name was given and auto-detection is disabled
Could not pick 8ebea123853128ca2411b2b449f76a1a4b0d026c
and dumped in the middle of an interactive rebase that you cannot
complete. OTOH, that is how a regular non-interactive merge works. And
if your next step is to set up your ident, then it's natural to do:
git config user.email whatever
git rebase --continue
So I'd lean towards dropping it, but maybe there are other hidden
gotchas.
-Peff