On Wed, May 24, 2017 at 07:40:08AM +0900, Junio C Hamano wrote: > > 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... I just meant that if the point of the optimization was to avoid invoking git-rebase (because it's slow), then we're still not optimizing out a process. It only helps at all because "rebase" (being a shell script) may be slower to start and realize it's a fast-forward than "merge". But once that is no longer true of git-rebase, then there is no purpose to the optimization. > > 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. Yeah, I'd agree. I had the impression the original change was motivated by gut feeling. -Peff