Junio C Hamano venit, vidit, dixit 01.03.2011 02:05: ... > * mg/rev-list-one-side-only (2011-02-22) 6 commits > - t6007: test rev-list --cherry > - log --cherry: a synonym > - rev-list: --left/right-only are mutually exclusive > - rev-list: documentation and test for --left/right-only > - t6007: Make sure we test --cherry-pick > - revlist.c: introduce --left/right-only for unsymmetric picking > > Will merge to 'next'; somebody may want to try losing many lines from > format-patch before it hits 'master', though. Hint, hint... I was looking at f-p and also cherry, and getting second thoughts on "--cherry" in the course of it. Would you hold back the top 2, please? I'm wondering whether we should make "rev-list --cherry" more close to "cherry" (which also takes up your suggestion to show equivalent commits). With the top 2, "--cherry" lists the "+" commits only. I'm thinking of something like "--cherry-mark" which is like --cherry-pick but marks equivalent commits (with a new flag PATCHSAME) rather than dropping them. Then, git rev-list --cherry-pick --no-merges --left-right --right-only A...B would be equivalent to git cherry A B but would make a lot of sense without --right-only, as well. I have a monkey patch for that right now (to be polished) which uses "=" because "-" is taken for boundary commits already. (I also noticed "^" for UNINTERESTING - when do they get shown??) I'm wondering about the relation between --cherry-mark and --left-right though: Should the former imply the latter, or should --cherry-mark always output '='? I guess the latter. If we were/are open to changing the characters which "git cherry" uses as markers we could probably replace it by the invocation above. The alternative (overload the meaning of '-') does not look like the best solution. Michael -- 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