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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

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