Re: [PATCH 1/3] revlist.c: introduce --cherry for unsymmetric picking
- From
Jay Soffian <jaysoffian@gmail.com>
- Date
- Feb 19, 2011, 14:47 UTC
- Message-ID
- <AANLkTinGkT0AJ6qeGi_z7Ck8wWM-jriUTqjDPvumjRwB@mail.gmail.com>
- In-Reply-To
- <7vzkptnn7x.fsf@alter.siamese.dyndns.org>
On Fri, Feb 18, 2011 at 2:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> 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.