On Wed, Sep 07, 2016 at 06:01:01PM -0400, Jeff King wrote: > Here's a re-roll of the series I posted at: > > http://public-inbox.org/git/20160907075346.z6wtmqnfc6bsunjb@xxxxxxxxxxxxxxxxxxxxx/ > > 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). Thanks. I'd love to see a more resilient patch-id mechanism, to make it easier to match up patches between branches. I don't think it makes sense to talk about the patch-id of a merge commit (though it might make sense for a merge which makes additional changes not present in any of the parents). Even if someone wants to match up merge commits with merge commits, I don't think that should happen via patch-id; I think that should happen in terms of "what patches does this merge introduce", without constructing a merge-patch-id via a Merkle tree of commit patch-ids. So, I think this patch series makes sense (modulo the comments about the commit message in patch 3). We already don't respect merge commits when doing format-patch; this seems consistent with that. If we ever make it possible for format-patch to handle merge commits, then we should also allow it to have merge commits as prerequisites. - Josh Triplett