From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/3] revlist.c: introduce --cherry for unsymmetric picking
Date: Mon, 21 Feb 2011 13:24:18 +0100 [thread overview]
Message-ID: <4D625972.4090500@drmicha.warpmail.net> (raw)
In-Reply-To: <7vzkptnn7x.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 18.02.2011 20:42:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> The existing "--cherry-pick" does not work with unsymmetric ranges
>> (A..B) for obvious reasons.
>>
>> Introduce "--cherry" which works more like "git-cherry", i.e.: Ignore
>> commits in B which are patch-equivalent to patches in A, i.e. list only
>> those which "git cherry B A" would list with a "-". This is especially
>> useful for things like
>>
>> git log --cherry @{u}..
>>
>> which is a much more descriptive than
>>
>> git cherry @{u}
>>
>> and potentially more useful than
>>
>> git log --cherry-pick @{u}...
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>
> A few comments.
>
> As a Porcelain tool, "log --cherry @{u}.." may very well be useful; what
> do I have that I still need to send. It is the moral equivalent of what
> format-patch does internally.
>
> However I don't find it "works more like 'git-cherry'" at all. The point
> of the command is to show _both_ what are still left to be sent, and what
> are already accepted. So it is very much inherently a symmetric-range
> operation.
Maybe I should have said "works more like I use git-cherry"... Whenever
I use it, I'm interested in one side only.
> At the plumbing level (which 'git-cherry' was designed to be),
> we should be able to ask for either (or both). Adding a "we are only
> interested in the right hand side" as a rev-list option is somewhat
> distasteful and short-sighted.
I don't understand this remark - isn't that exactly what you suggest
below ("--right-only")? Then what is distasteful and short-sighted?
I don't propose changing any current functionality of "git cherry" not
"git rev-list --cherry-pick".
> I wonder if you can instead extend the revision walking machinery by just
> adding a filter that says "show me only the left/right hand side" [*1*]?
> I.e.
>
> git rev-list --right-only --oneline --cherry-pick @{u}...
>
I think that is basically what I have done, just that I only implemented
the shortcut option you describe in the next paragraphs:
> If that is done, we could ask for "--left-only" when we wanted to.
>
> As there are by definition more contributors than integrators, naturally
> we can expect that "--right-only" would be a lot more often used mode of
> operation than "--left-only", and I don't mind to have "--cherry" as a
> synonym to trigger "--cherry-pick --right-only" (and perhaps internally
> turn a two-dot automatically into three-dot), so that you can say
>
> git log --cherry @{u}..
>
> from the command line to get the same effect.
>
> 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
Could you explain in what way the current implementation is not done
"properly"? I introduced a flag for the walker and act on the flag. I
don't see a way to cut down the walk further since we need the other
side for the patch-id comparisons.
> 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.
>
> The get_patch_ids() function itself can go, and its caller and the
> codepaths that use has_commit_patch_id() would be vastly simplified, no?
I have not looked at format-patch at all. Also, I tend to forget
--ignore-if-in-upstream. In fact, git-format-patch(1) carefully avoids
any mentioning of "cherry" to the extent that it's difficult to
recognize as the same concept at all. I would suggest renaming it
"--cherry" or "--cherry-pick" in 1.8.0.
So I think the plan is:
- use a "right-only" flag rather than "cherry"
- make "--cherry" do "--cherry-pick --right-only" (with or without
".."->"...")
- simplify cmd_format_patch
Please stop me if I misunderstood you ;)
Michael
next prev parent reply other threads:[~2011-02-21 12:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-18 12:34 [PATCH 1/3] revlist.c: introduce --cherry for unsymmetric picking Michael J Gruber
2011-02-18 12:34 ` [PATCH 2/3] t6007: Make sure we test --cherry-pick Michael J Gruber
2011-02-18 12:34 ` [PATCH 3/3] rev-list: documentation and test for --cherry Michael J Gruber
2011-02-18 19:42 ` [PATCH 1/3] revlist.c: introduce --cherry for unsymmetric picking Junio C Hamano
2011-02-19 14:47 ` Jay Soffian
2011-02-21 12:24 ` Michael J Gruber [this message]
2011-02-21 16:09 ` [PATCHv2 1/2] revlist.c: introduce --left/right-only " Michael J Gruber
2011-02-21 16:09 ` [PATCHv2 2/2] rev-list: documentation and test for --left/right-only Michael J Gruber
2011-02-21 17:37 ` Jay Soffian
2011-02-22 7:23 ` Michael J Gruber
2011-02-22 0:48 ` [PATCHv2 1/2] revlist.c: introduce --left/right-only for unsymmetric picking Junio C Hamano
2011-02-22 1:17 ` Junio C Hamano
2011-02-22 1:19 ` Junio C Hamano
2011-02-22 13:36 ` [PATCH (n+1)/n] t6007: test rev-list --cherry Michael J Gruber
2011-02-21 19:49 ` [PATCH 1/3] revlist.c: introduce --cherry for unsymmetric picking Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D625972.4090500@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).