Hi Peff, On Wed, 7 Sep 2016, Jeff King wrote: > Michael and I found a case where the "format-patch --cherry-pick A...B" > command for a rebase took over 7 minutes to run with git v2.9.3. Yikes. > > Switching to v2.10 dropped that to a bit over 3 minutes (due to the > kw/patch-ids-optim topic). Better, but not great. I agree: not great, but better... > The culprit turned out to be merge commits; the patch-id code will > happily diff a merge against its first parent, and ignore the rest. This > _seems_ like a bad idea, but maybe there is something clever going on > that I don't know about. I couldn't find anything useful in the history, > and given that this code was adapted from rebase, my guess is that it > was never really intended to handle merge commits in the first place (of > course we weren't trying to rebase merge commits; but it has to generate > patch-ids for everything that happened on "A" to compare against). > > Dropping the computation of the merge commits got it down to about 4 > seconds. I also noticed that it was doing rename detection (which also > seems like a bad idea). Disabling renames dropped another half second or > so. That makes for a really nice improvement! > This is marked as "RFC" because I don't feel entirely confident that I'm > not missing some clever need for these options. But in both cases my gut > feeling is that they are simply unintended effects that nobody ever > noticed, because it would be very rare that they would affect the > output. And that if they _did_ affect the output, they would probably be > doing the wrong thing. Given that the patch ID is *wrong* for merge commits (it only looks at the first parent, so each "-s ours" merge will have the same patch ID!), I would say that we can get away with re-defining the patch ID of merge commits. The only case where it might change things that I can think of would be a `git rebase --preserve-merges`: it would probably have worked *by chance* before (or not, in case of "-s ours" merges), and now it would try to pick the merge commits even if rebased versions were already merged upstream. If I read the --preserve-merges code correctly, that would result in the merge commit's parents to be 'rewritten' to HEAD. And as both parents would be rewritten to HEAD, they would be condensed into a single new parent, resulting in a cherry-pick that fails (because it tries to cherry-pick a merge commit without any -n option). Of course, what we could do is to introduce a modifier, e.g. --cherry-pick=first-parent, that would trigger the old behavior and would be asked-for in the --preserve-merges mode. But quite frankly, personally I would not worry about it *that* much. As you pointed out, the patch ID for merge commits is incorrect to begin with, and we may just redeclare all merge commits to be incomparable to one another when it comes to patch IDs. In short: I would be fine with the change of behavior. Ciao, Dscho