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

[Maritza Mendez]

Stephen... No.  I'm trained as a mathematician.  So when I write that
bzr log -r3..1 includes 3 and 1 I am not excluding 2.  I am stating a
fact about set membership, not providing an algorithm for constructing
that set.  Now you see why mathematicians have to drink coffee with
each other...no one else wants to!   :)

Thanks for asking.  My meaning may have been unclear to others as well.

Btw... If anyone wants to debate the implicit role of the axiom of
choice I'll be at the bar.

~M



On 7/10/09, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 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.
>
>