On Sun, Aug 20, 2017 at 04:56:50PM -0700, Junio C Hamano wrote: > 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*], > [...] > *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
