Re: [RFC/PATCH v2 0/3] patch-id for merges
On Wed, Sep 07, 2016 at 03:51:04PM -0700, Josh Triplett wrote: > > 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. Thanks for the input. I knew that format-patch doesn't show merge commits, but I didn't realize that merges were skipped entirely for the base preparation (but I see it now; there is a "rev.max_parents = 1" setting in prepare_bases). So this really doesn't change the output there at all. And in fact, the switch to: if (commit_patch_id(commit, &diffopt, sha1, 0)) - die(_("cannot get patch id")) + continue; should never hit that continue. It could be: die("BUG: somehow a merge got fed to commit_patch_id?"); but the "continue" somehow seems like the right thing to me. I'll wait another day or so for comments and then send the re-roll using this approach. -Peff
Re: [RFC/PATCH v2 0/3] patch-id for merges
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.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). 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
[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.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