From: Jay Soffian Date: Sat, 19 Feb 2011 14:47:48 GMT Subject: Re: [PATCH 1/3] revlist.c: introduce --cherry for unsymmetric picking Message-ID: In-Reply-To: <7vzkptnn7x.fsf@alter.siamese.dyndns.org> On Fri, Feb 18, 2011 at 2:42 PM, Junio C Hamano 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.