Subject: Re: Question about right-only

From: Tajti Ákos <[email-masked]>
Date: Tue, 06 Sep 2011 17:42:26 +0200

Thanks four your answer, it was really great help (cleared up everything)!

Best regards,
Ákos Tajti

2011.09.06. 17:24 keltezéssel, [email-masked] írta:
> On Tue, 06 Sep 2011 13:44:50 +0200, Tajti wrote:
>
>> what does the right-only option of git-log actually do? The manual is
>> not too verbose about it.
> The documentation is indeed a bit messy, so let me rearrange it for you.
>
>  From `git help rev-parse':
>
>    r1...r2 is called symmetric difference of r1 and r2 and is
>    defined as `r1 r2 --not $(git merge-base --all r1 r2)'. It is
>    the set of commits that are reachable from either one of r1 or
>    r2 but not from both.
>
> Then we have this from `git help log':
>
>    --left-right
>        Mark which side of a symmetric diff a commit is reachable
>        from. Commits from the left side [(r1 above)] are prefixed with
>        <  and those from the right [(r2 above)] with>...
>
> which should explain what `<' and `>' mean in the following from
> `git help log':
>
>    --left-only, --right-only
>        List only commits on the respective side of a symmetric
>        range, i.e. only those which would be marked<  resp.>  by
>        --left-right.
>
> This is probably most useful with the following option, described
> in `git help log':
>
>    --cherry-pick
>        Omit any commit that introduces the same change as another
>        commit on the "other side" when the set of commits are
>        limited with symmetric difference.
>
>        ...
>
>        For example, --cherry-pick --right-only A...B omits those
>        commits from B which are in A or are patch-equivalent to a
>        commit in A. In other words, this lists the + commits from
>        git cherry A B. More precisely, --cherry-pick --right-only
>        --no-merges gives the exact list.
>
> That is, you often run into multiple commit objects that are unique
> because of, say, differing commit dates, but that actually introduce
> the same change to the source; this combination of options is helpful
> in weeding out commits that introduce the same change.
>
> If you're still confused, don't hesitate to poke the list some more;
> the documentation is quite lacking over all topics, so don't feel
> stupid.