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