2

I have created a test git project to figure out how should I get the differ logs between two branches.

In most case, we will have such a case: branch master has cherry-picked some commits to master,see below graph: enter image description here

The "I" commit is cherry-picked to master branch. My expected result of differ logs between master and dbg_feature should be "J" only.

But actually, when I run below command:

git cherry -v master dbg_feature

I will get "I" and "J", the cherry-picked one "I" still list in it:

+ a1915061be2f445d322abc7bfb7d19bbb357b917 I
+ 6486e899e07b6d6f539cbcad10655dcc345f434d J

If I run below command:

git log --oneline --no-merges master..dbg_feature

the output is below:

6486e89 J
a191506 I

If run git rev-list command as below:

git rev-list --oneline --no-merges --cherry-pick --right-only master...dbg_feature
6486e89 J
a191506 I

Result seems the same as git log.

So what's the right command to get the exact differ logs between this two branches?

lucky1928
  • 8,708
  • 10
  • 43
  • 92
  • cherry-pick commits will be treated as a new commit, so I think it's impossible to get such a differ to filter out the cherry-picked commits. if everything is merged, it should be fine. – beetlej May 21 '16 at 01:42
  • A bit strange, according to the output, "I" and "J" should be commits of dbg_feature but not of master. Besides, master does not have any equivalent commits to I or J. If it has an equivalent commit to I, the + should be -. – ElpieKay May 21 '16 at 02:10
  • @ElpieKay Yeah, because I has been cherry-picked to master but that command seems don't know it. – lucky1928 May 21 '16 at 02:13
  • The two-dot syntax `master..dbg_feature` is limited to acting on the commit graph. It *does not* examine the *contents* of commits; it looks only at the graph. See my answer below for modifiers that *do* examine contents of commits. They should generally be applied only after using a symmetric difference (three-dot syntax) to do graph operations that select commits that are on either the left or right sides, but not common to both. – torek May 21 '16 at 02:16
  • Was there any conflict when cherry-picking "I" from dbg_feature to master? Make a patch of I in dbg_feature and a patch of I in master, and check if the 2 patches are equivalent. – ElpieKay May 21 '16 at 02:22
  • @ElpieKay yes, when cherry-pick I to master, there has conflict,after resolve the conflict, then do the cheery-pick.Does that means it's a new commits so can not say it's "I"? – lucky1928 May 21 '16 at 02:25
  • @lucky1928 Yes, in most cases the conflict-resolved commit is not equivalent any more. Maybe it still is if a recursive strategy with a `theirs` option is used but I'm not sure. – ElpieKay May 21 '16 at 02:31
  • @ElpieKay Just try to cheery-pick a no conflict commits (add a new file only). it seems behavior the same, so it doesn't matter conflict or it, cherry-pick will always get a new commit. – lucky1928 May 21 '16 at 03:13
  • @lucky1928 still "+ sha1"? I think it should be "- sha1" if a non conflict cherry-pick is made. – ElpieKay May 21 '16 at 03:17
  • If you had to resolve a conflict during cherry-picking, the new commit *will not be patch-equivalent* to the original commit. To see this for yourself, run `git show` on the two commits and compare the diffs. – torek May 21 '16 at 04:48

1 Answers1

0

It's not clear to me what you mean by "differ commits". However, your mention of using git cherry suggests that you are talking about what the git rev-list documentation refers to as "equivalent" or "patch-equivalent" commits (or their opposite, which I and they call "inequivalent" commits):

--cherry-mark

      Like --cherry-pick (see below) but mark equivalent commits with = rather than omitting them, and inequivalent ones with +.

--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, if you have two branches, A and B, a usual way to list all commits on only one side of them is with --left-right (see the example below in the description of the --left-right option). However, it shows the commits that were cherry-picked from the other branch (for example, “3rd on b” may be cherry-picked from branch A). With this option, such pairs of commits are excluded from the output.

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

      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.

--cherry

      A synonym for --right-only --cherry-mark --no-merges; useful to limit the output to the commits on our side and mark those that have been applied to the other side of a forked history with git log --cherry upstream...mybranch, similar to git cherry upstream mybranch.

Again, all of these are arguments to the git rev-list command. Since git rev-list and git log are pretty much the same command (except for minor details like their output format :-) ), they work with git log as well.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Maybe differ logs is more meaningful? Updated. Command "git rev-list --oneline --no-merges --cherry master..dbg_feature" seems output the same. I and J but not J only. – lucky1928 May 21 '16 at 02:17
  • My stumbling block is the word "differ". This is an English word, but as a word, it is a verb: Fred and Bob differ, while Bob and Carol agree. (See http://www.dictionary.com/browse/differ) Saying "logs differ" would mean, for instance, that you ran `git log A` and `git log B` and got different output, which is not surprising but seems to have nothing to do with your actual question. Meanwhile, note the *important note* that these `rev-list` flags are to be used with the *three* dot syntax. – torek May 21 '16 at 04:46