"Philip Oakley" <philipoak...@iee.org> writes: >> Philip probably has a >> confused notion that "rev-list A..B C..D" is somehow a union of set >> A..B and C..D? > > That wasn't the issue. Though it does beg the question that it's the > same as "rev-list D B ^A ^C" isn't it?

## Advertising

If you think it begs the question, then you haven't understood what I meant by all of the explanation. Let me repeat: "A..B C..D" is exactly a short-hand for "^A B ^C D" which is the same as ANY permutation like "D B ^A ^C". This is because rev-list machinery NEVER does "ah the command line asks for two or more sets to be computed and then a union of the results to be returned". As I said, it collects positive starting points (B and D) and negative starting points (A and C), and does a single traversal "ones that are reachable from positives, excluding the ones that are reachable from negatives". That is all it does. Once that is understood, it should be obvious that it would not have any effect on the result to permute the order of positives and negatives. > I'd say it was the walk - no walk range confusion. You may _additionally_ have had that confusion ;-). > i.e. cherry-pick B D F G Q..T; isn't B D F G R S T, is it? Of course it isn't, but that is not about any ordering. It is because the machinery does not work this way: - we have positives B D F G and ... oh wait, we see Q..T, so we need to traverse ONLY that bit and come up with positives in the resulting set, which are R S T, and take a union of all of the above; and then - now we process --no-walk to show only the resulting positives. The "--no-walk" tells the rev-list machinery "I have only positives; do not traverse from them AT ALL but just use these positives". Only under that condition, the order of the positive ends you list on the command line matters. Having ^Q in the input "B D F G ^Q T" contradicts that "I have only positives" precondtion and forces the machinery to traverse, i.e. to find things reachable from B D F G T excluding things reachable from Q. The order of the output would be topological (i.e. a parent is not shown until all its children are), with or without --date-order, and may not match the order you gave the positive ones from the command line. You may want the "exclude things reachable from Q" part to not have any effect on things related to B, D, F or G, but the machinery does not work that way. That is because there is only one single traversal and no union operation involved. It is a different matter Git born in a fictional world that takes A..B C..D as a union of two sets is better than the current one. There might be cases where such a variant of "a set of commits that is a union of multiple sets" is handy to use. But I think we are talking about what Git in our world does, so I'd not go there in this discussion.