Re: potential improvement to 'git log' with a range

On Fri, 9 Apr 2010, Aghiles wrote:

Well, technically ".." means two different things

 - for "set operations" (ie "git log" and friends) it's the "relative 
   complement" of two sets (or "'reachable from A' \ 'reachable from B'").

 - for "edge operations" (ie "git diff" and friends) it's just two 
   end-points (aka "range"). A diff doesn't work on sets, it only works on 
   the two endpoints.

It's arguably a bit confusing, but quite frankly, the room for confusion is very small, and the biggest source of confusion is probably not so much that ".." means two different things in two (clearly different) contexts, as much as just the fact that people aren't used to thinking in terms of set operations at all.

Most SCM's really talk about "ranges". Once you think in those terms, complex history doesn't work. Git very fundamentally is much about set theory, and "ranges" is a bad word to use.

To make things even more exciting triple-dot, "A...B" has two different meanings too, again one that is about sets ("symmetric difference") for the log-based ones, and one that is a somewhat badly defined range for the diff based ones (where the end-points are "one common nearest ancestor of A and B" and "B" respectively).

It's all actually very natural when you get used to it, although that "A...B" as a range really isn't well-defined, since there can be more than one common nearest ancestors. It's still often enough useful in practice that I wouldn't get rid of it, but it's not the greatest feature.

		Linus