Andrew Ardill <andrew.ardill@xxxxxxxxx> writes:
> Is there any reason `git pull` can't delay that check until the point
> where it actually tries to create a new commit? It's fair enough to
> error if a new commit needs to be made, and there is no user
> configured, but for the use cases discussed here it seems a little
> eager to error on the chance that the user will be needed.
I personally do not think it is a good trade-off.
In theory [*1*], it _is_ possible to delay the "the given identity
looks bogus" check so that the underlying "git fetch" is done
without it, and bypass the check when "pull" fast-forwards, as there
is no need for an extra merge commit in such a case as you noticed.
We still do record the bogus identity in the reflog of the HEAD ref,
but IIRC, we do not trigger a severe error when a bogus identity is
only needed for reflogs.
But before running "fetch", you cannot tell if the "pull" will
fast-forward, so such an "optimization" may actually be a net loss
for end users, who have to wait for network delay only to be told
that you'd end up with a history with bogus identity and need to
redo the operation after fixing your identity. Then after that,
they are likely to do another "git pull", which will avoid the cost
of retransmission of objects if (and only if) the initial "git pull"
uses remote-tracking branches.
[Footnote]
*1* We actually might already do such an "optimization"; I didn't
check.
