Bagas Sanjaya <bagasdotme@xxxxxxxxx> writes: > On 18/05/21 18.17, Junio C Hamano wrote: >> ... >> +In other words, writing two "two-dot range notation" next to each >> +other, e.g. >> + >> + $ git log A..B C..D >> + >> +does *not* specify two revision ranges for most commands. Instead >> +it will name a single connected set of commits, i.e. those that are >> +reachable from either B or D but are reachable from neither A or C. >> +In a linear history like this: >> + >> + ---A---B---o---o---C---D >> + > > So "git log A..B C..D" is same as "A..D", right? A..B C..D is equivalent to ^A ^C B D, and in order to be part of the set it represents, a commit must not be reachable from A, must not be reachable from C, and must be reachable from B or D. In the picture, A, B and two o's are all reachable from C, therefore are not part of the set A..B C..D represents. Neither is C, as it is reachable from C. That leaves only D in the resulting range. A..D is a set of connected five commits, B o o C D in the above picture. So, no. 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).
