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

From: Junio C Hamano <gitster@pobox.com>
Date: May 23, 2017, 22:40 UTC
Message-ID: <xmqqa863jiyf.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170523131231.zqjkymypbilv6tyf@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 16 quoted lines

> ...we can probably restrict it to when autostash is in use, like:
>
>   /*
>    * If this is a fast-forward, we can skip calling rebase and
>    * just do the merge ourselves. But we don't know about
>    * autostash, so use the real rebase command when it's in effect.
>    */
>   if (!autostash && is_descendant_of(merge_head, list)) {
> 	opt_ff = "--ff-only";
> 	return run_merge();
>   }
>
> AFAICT from the commit introducing this code (33b842a1e9), and the
> surrounding discussion:
>
>   http://public-inbox.org/git/OF95D98CB6.47969C1C-ONC1257FE1.0058D980-C1257FE1.0059986D@dakosy.de/T/#u

Sounds like a sensible solution.

> But I notice on the run_merge() code path that we do still invoke
> git-merge.

... wouldn't that what we want even when the merge happens to be a fast-forward one? I am not sure what you meant by this, but...

> And rebase has been getting faster as it is moved to C code
> itself. So is this optimization even worth doing anymore?

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

Thanks.