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, , 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
