[RFC/PATCH v2 0/3] patch-id for merges

Here's a re-roll of the series I posted at:

  http://public-inbox.org/git/20160907075346.z6wtmqnfc6bsunjb@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