Here's a re-roll of the series I posted at: http://public-inbox.org/git/20160907075346.z6wtmqnfc6bsu...@sigill.intra.peff.net/
Basically, it drops the time for "format-patch --cherry-pick" on a particular case from 3 minutes down to 3 seconds, by avoiding diffs on merge commits. Compared to v1, it fixes the totally-broken handling of commit_patch_id() pointed out by Johannes. We can drop the diffs on the merge commits because they're quite broken, as discussed in the commit message of patch 3 (they don't take into account any parent except the first). So what do we do when somebody asks for the patch-id of a merge commit? This is still marked RFC, because there are really two approaches here, and I'm not sure which one is better for "format-patch --base". I'd like to get input from Xiaolong Ye (who worked on --base), and Josh Triplett (who has proposed some patches in that area, and is presumably using them). Option one is that merges are defined as having no patch-id at all. They are skipped for "--cherry-pick" comparison, and "format-patch --base" will not mention them at all as prerequisites. That's what I've implemented here. Option two is to use the commit sha1 as the patch-id for a merge, making it (essentially) unique. That gives us a defined value, but it's one that "--cherry-pick" will not match between two segments of history. I don't know if having _some_ defined value is useful for "format-patch --base" or not. And obviously there's an option 3: define some more complicated patch-id for merges that takes into account all of the parents. I didn't think too much on that because I don't really see value in it over using the commit sha1, and it would be computationally expensive. [1/3]: patch-ids: turn off rename detection [2/3]: diff_flush_patch_id: stop returning error result [3/3]: patch-ids: use commit sha1 as patch-id for merge commits -Peff
