Jeff King <p...@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.00599...@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.
