On Tue, Jul 12, 2011 at 05:36:07PM -0400, Jeff King wrote: > > In the normal case of applying patch B on top of patch A, it doesn't > matter if we use per-hunk patch-ids or normal patch-ids. Because even if > we decide to actually go through with the merge of B on top of A, any > hunks that _would have_ had their per-hunk patch-ids match will merge > cleanly. > > But in the real world, it is about applying patch Z on top of patches > A..Y, where Z has similar hunks to patch N. And then it _does_ make a > difference, because it is about skipping hunks from Z that are already > in N, but will end up applied on top of Y. And what's in Y and what's in > N may be quite different. > > Does that sound right? Yes, exactly. And one possible solution would be to drop all hunks from Z which are already somewhere in A..Y. But that undermines the whole changeset idea. If we detect the similarities between Z and N, then we could rebase Z to N, make the user resolve any conflicts, which should make more sense than what we would have between Z and Y. Then we have Z' on top of N: Z Z' Z" / / / A--..--N--..--Y Subsequently we rebase Z' to Y, at which point only changes remain that we disagreed with. For those we may have to do conflict resolution again. So, in some cases this approach could result in more work. Clemens -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html