Re: `pull --rebase --autostash` fails when fast forward in dirty repo

From: Jeff King <peff@peff.net>
Date: May 25, 2017, 18:22 UTC
Message-ID: <20170525182230.552dif62zqxuufk3@sigill.intra.peff.net>
In-Reply-To: <20170525180407.ni2oed5wk3qsd2ch@sigill.intra.peff.net>

On Thu, May 25, 2017 at 02:04:07PM -0400, Jeff King wrote:

Show 6 quoted lines

> > ...that might be something worth thinking about---my gut feeling
> > tells me something but we should go by a measurement, not by gut
> > feeling of a random somebody.
> 
> Yeah, I'd agree. I had the impression the original change was motivated
> by gut feeling.

Hmph. On Linux, at least, I do not see that using "git merge" to fast-forward is appreciably faster:

Here are timings for:

  git reset --hard HEAD~10 && git pull --rebase

in a git.git repo, using builds of git from various commits (all best-of-five; the timings include the reset for simplicity, but presumably it costs the same in each case):

  - 33b842a1e^ (just prior to the switch to git-merge)
    real  0m0.256s
    user  0m0.096s
    sys	  0m0.020s

  - 33b842a1e  (using git-merge)
    real  0m0.227s
    user  0m0.092s
    sys	  0m0.020s

So a little faster, but there seems to be 20-30ms of noise in my timings anyway (the average for the "prior" case did seem to be higher, though). It's possible that the difference would be more stark on Windows, where the cost of the shell script would be higher.

The same test with the current master performs the same as 33b842a1e. But if I then remove the optimization, as Tyler's patch did at the start of this thread, the timings are similar to 33b842a1e^.

So I dunno. It does not seem appreciably faster, but what little speedup it does provide is the same even with a more modern rebase. Which is probably because that rebase isn't actually doing much in the first place, so the optimized bits from Dscho's rebase--helper are not kicking in yet.

Anyway. All this has shown me is that it's probably pointless to do this timing at all on Linux. Somebody on Windows might get better results.

But regardless, we need to do something. Correctness must trump optimizations, and the question is whether we can throw out the whole conditional, or if we should just restrict when it kicks in.

-Peff