Re: What's cooking in git.git (Feb 2011, #07; Mon, 28)

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Mar 5, 2011, 17:04 UTC
Message-ID: <4D726D1A.50507@drmicha.warpmail.net>
In-Reply-To: <7vbp1vfy5f.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 01.03.2011 02:05: ...

Show 10 quoted lines

> * 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