Re: Please fix the useless email prompts

From: Jeff King <peff@peff.net>
Date: Aug 23, 2017, 15:35 UTC
Message-ID: <20170823153553.jg4g55f4biqzu5mw@sigill.intra.peff.net>
In-Reply-To: <xmqqinhh7pz1.fsf@gitster.mtv.corp.google.com>

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

Show 14 quoted lines

> Andrew Ardill <andrew.ardill@gmail.com> 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*],
> [...]
> *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).

Show 8 quoted lines

> 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