Re: Please fix the useless email prompts

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 20, 2017, 23:56 UTC
Message-ID: <xmqqinhh7pz1.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAH5451kcb0Y4mm2U804ruqBewB2AV991Hm0_-8ExdEoDTF8DJw@mail.gmail.com>

Andrew Ardill <andrew.ardill@gmail.com> writes:

Show 5 quoted lines

> 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.