On Fri, Feb 11, 2011 at 12:40:29PM +0100, Johan Herland wrote: > > I don't know very much about how git really works so what I'm saying > > may be dumb, but rather than record where a commit came from, would it > > be reasonable for rebase to look at the patch-id for each change on > > the topic branch after the merge base and automatically remove topic > > branch commits that match that patch-id? So in your example, rebase > > would check each topic branch commit against 3', d, e*, and f and see > > that the 3' patch-id is the same as the topic branch 3 and remove > > topic branch 3 before it gets to e*? > > I believe "git rebase" already does exactly what you describe [1]. Yep. It uses format-patch's "--ignore-if-in-upstream", which computes patch-ids (you can get the same list with "git cherry"). > However, comparing patch-ids stops working when the cherry-pick (3 -> 3') > has conflicts. IINM, it is the conflicting cases that John is interested in > solving... Exactly. One other possible solution to this problem would be to somehow make patch-ids handle fuzzy situations better. I doubt it is possible to do that without introducing a lot of false positives, though. -Peff -- 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