2

Compare What are the differences between double-dot ".." and triple-dot "..." in Git commit ranges?, a more frequently useful question.

I'd like to clarify whether the following produce the same set of commits as git log A..B:

# version 1
git log --right-only A...B 

# version 2
#
# (The sed part keeps only the righthand lines, and strips the > character)
git log --left-right --format=oneline A...B | sed -n "s/^>//p"

They would seem to be more roundabout ways of accomplishing the same thing.

The initial motivation was to get a deeper understanding of the meaning of these commands, which involve ignoring already-cherry-picked commits:

# version 1a
#
# Literally taken from the git-log help page, which explains what this means
git log --cherry-pick --right-only A...B 

# version 2a
#
# This is a simplified version of something in the git code. (In particular,
# in git-rebase--interactive.sh.)
git log --left-right --cherry-pick --no-merges --format=oneline A...B | sed -n "s/^>//p"

An extension of this question is to ask why symmetric difference (ie triple-dot) is required to do this sort of "one-sided" cherry-pick elimination. For example, to find the unique commits on B, including a correction for cherry picks, shouldn't one be able to do something as simple as

git log --cherry-pick A..B

I suppose it's because git applies the cherry-pick-removing logic after it's filtered out all the A commits with A..B. (That is, in this hypothetical command git throws away anything related to A before trying to apply cherry-picking logic.)

Community
  • 1
  • 1
Chris
  • 9,986
  • 8
  • 48
  • 56

1 Answers1

0
git log --cherry-pick A..B

Is the same as

git log --cherry-pick ^A B

Which is basically all the B commits, that are note part of A. If all the A commits are dropped, then to what is Git supposed to compare the cherry-pick?

FelipeC
  • 9,123
  • 4
  • 44
  • 38