Re: Please fix the useless email prompts

On Sun, Aug 20, 2017 at 04:56:50PM -0700, Junio C Hamano wrote:

Andrew Ardill [off-list ref] writes:

quoted

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*],
[...]
*1* We actually might already do such an "optimization"; I didn't
    check.

I think we already do. Reflogs do not ask for strict identity, and we've
addressed similar cases (e.g., 1e461c4f1fc which was motivated by
pull.rebase not handling this).

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.

I agree that in the common case where the command might or might not
need to create a commit, it's nicer if we tell the user up front.

But there are also cases where the user can reasonably expect that a
commit will not need to be created. Certainly --ff-only is one hint. But
in general a pull-only repository for testing will just see repeated
fetch+fast-forward pulls. People with that kind of setup would see it as
a regression if pull started failing to say "I don't know yet whether
we'll need to create a commit, but I'm failing early to let you know
that it won't work".

If we could reliably tell the difference between those two cases, it
might be worth doing the up-front check. But I'm not sure we can do that
without declaring that people in the ff-only case should be using a
different workflow (e.g., fetch + "reset --hard").

-Peff