Subject: Re: Question about "git log --cherry"

From: John Keeping <[email-masked]>
Date: Fri, 27 Sep 2013 10:14:02 +0100

On Fri, Sep 27, 2013 at 10:28:05AM +0200, Francis Moreau wrote:
> On Fri, Sep 27, 2013 at 10:11 AM, John Keeping <[email-masked]> wrote:
> > On Fri, Sep 27, 2013 at 07:09:03AM +0200, Francis Moreau wrote:
> >> Hi,
> >>
> >> On Thu, Sep 26, 2013 at 10:21 PM, John Keeping <[email-masked]> wrote:
> >> > On Thu, Sep 26, 2013 at 06:35:57PM +0200, Francis Moreau wrote:
> >> >> I'm trying to use "git log --cherry ..." in order to display new, kept
> >> >> and removed commits between two branches A and B.
> >> >>
> >> >> So commits which are only in B are considered new and should be marked
> >> >> with '+'. Commits which are in both branches are marked with '=' but
> >> >> only commit in branch B are shown. Eventually commits which are in A
> >> >> but not in B anymore should be marked with '-'.
> >> >>
> >> >> So far I found this solution:
> >> >>
> >> >>   $ git log --cherry-mark --right-only A...B
> >> >>   $ git log --cherry-pick  --left-only   A...B
> >> >>
> >> >> but I have to call twice git-log. This can be annoying since depending
> >> >> on A and B, calling git-log can take time.
> >> >>
> >> >> Is there another option that I'm missing which would do the job but
> >> >> with only one call to git-log ?
> >> >
> >> > Does this do what you want?
> >> >
> >> >     git log --cherry-mark --left-right A...B |
> >> >     sed -e '/^commit / {
> >> >         y/<>/-+/
> >> >     }'
> >>
> >> Nope because --left-right shows common commits (with '=' mark) that
> >> belong to A *and* B, and I'd like to have only the ones in B.
> >
> > I think the only way you can address this is to post-process the result,
> > I don't know any way to remove a left side commit only if it is
> > patch-identical to a right side commit.
> >
> > It should be relatively easy to filter out any '=' commits that are in
> > the output of "git rev-list --left-only A...B".
> 
> yes that's what I'm doing but I was wondering if that's possible to do
> that with only one run of git-log/git-rev-list.

I don't think it is.  But you only need to use the --cherry-mark option
with one of the runs, so the other one should be very quick - the added
work of calculating patch IDs slows down "git log" a lot.