[Merge] lp:~amanica/bzr/log_returns_too_much into lp:bzr

[Stephen J. Turnbull]

Maritza Mendez writes:

 > > log -v shows status between revisions; I think its entirely reasonable
 > > to see the same the same thing in log and diff.

Really?  You would really expect that bzr log -r 1:3 would produce
only the logs for revno 1 and revno 3, or that bzr diff -r 1:3 would
produce two diffs, one of revno 3 vs revno 2, then one of revno 2
vs. revno 1?  I find this very unintuitive.

I agree that the option to get diffs in log output is *very* useful,
but it's not the same thing as getting a difference between two
arbitrary revisions.

Personally I wouldn't allow range notation in a diff revision spec,
but as long as you do, it should be interpreted as a pair, not a
range.

 > Let us be at least semi-quantitative for a moment.  Consider the limiting
 > cases of empty intervals.
 > 
 > I think most of us would agree that
 > 
 >     bzr diff -rX..X
 > 
 > should always return the empty set.

Yes.

 > What then should
 > 
 >     bzr log -rX..X
 > 
 > return?  [...]  X must be the empty set for all X under whch bzr
 > log -rX..X is accepted as a valid syntax.  So if we reject this as
 > unpalatable nonsense,

Note that this is a different issue, of whether it makes sense for the
range to be left-open.

I wouldn't reject it.  For comparison, in git the range notation is an
abbreviation, where "Y..X" == "^Y X" which is the set intersection of
{r: r is not Y nor any ancestor of Y} with {r: r is X or an ancestor
of X}.  For Unix geeks, the "ancestry complementation operator" "^" is
very similar to the "-prune" operator of find(1).

Non-mathematicians may have trouble with it, but it is very convenient
for dealing with complex DAGs.