Re: Question about right-only
- From
- Tajti Ákos <akos.tajti@intland.com>
- Date
- Sep 6, 2011, 15:42 UTC
- Message-ID
- <4E663F62.7030603@intland.com>
- In-Reply-To
- <ec1404d75fd6461fa731f31625126884-mfwitten@gmail.com>
Thanks four your answer, it was really great help (cleared up everything)!
Best regards, Ákos Tajti
2011.09.06. 17:24 keltezéssel, mfwitten@gmail.com írta:
Show 52 quoted lines
> 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.