On 20/05/21 12.02, Junio C Hamano wrote:
The confusion we often see goes more like "The set A..B contains B
(and nothing else), and C..D contains D (and nothing else), hence
'git log A..B C..D' would show B and D". But that is not what
happens because "git log" (like most other commands) takes just a
"range" that is "A..B C..D", which is a set of connected commits
each of whose member is reachable from one of the "positive"
endpoints (like B and D) and is not reachable from any of the
"negative" endpoints (like A and C).
Well, apparently the proposed text may have failed to educate you
about what a "revision range" is and how it works, so it is not good
enough, so I'll postpone merging the change down further and see if
somebody else can come up with a better description.
Thanks.
From Pro Git book [1]:
The most common range specification is the double-dot syntax. This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another.
Say you want to see what is in your experiment branch that hasn’t yet been merged into your master branch. You can ask Git to show you a log of just those commits with master..experiment — that means “all commits reachable from experiment that aren’t reachable from master.”
If, on the other hand, you want to see the opposite — all commits in master that aren’t in experiment — you can reverse the branch names. experiment..master shows you everything in master not reachable from experiment
So in the first case, git log master..experiment shows all commits that
are only on experiment, while git log experiment..master shows all commits
that are only on master.
This above are often confused by most Git users, because they execute the
latter when they want semantics of the former.
I CC'ed Scott Chacon because he wrote the description about revision
range in Pro Git book. Let's see what his opinions are.
[1]: https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection
--
An old man doll... just what I always wanted! - Clara
