On Fri, Feb 18, 2011 at 2:42 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > By the way, when this feature is properly implemented internally at the > revision traversal level, we should be able to lose quite a lot of code > from builtin/log.c, as format-patch in it was the original implementation > of the whole thing, and it was done outside the revision walking machinery > to implement patch equivalence filtering of the traversal result. ÂWe > would essentially feed the symmetric upstream...HEAD range with the > cherry-pick flag, ask it to give only the right hand side (i.e. what are > left after the patch equivalence filter), and emit the result. Tangent: it occurred to me it would be useful to give the user some say in how the patch-id is computed. Currently, the patch-id is the hash of the diff hunks, which is very strict. I think it would be useful to have a "loose" mode of computing the patch-id. What I was thinking was to use the hash of certain commit metadata that is likely to be unique: say, the commit authorship (name, email, timestamp) + commit subject and/or body. This would allow rev-list to (optionally) filter out commits that, modulo conflict resolution, introduce the "same" change. IOW, give the user of rev-list some say about what a "same" commit is. (I suppose this is my itch to scratch.) :-) j. -- 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