[MERGE/RFC] log -n0 -r 1..1.1.1 skips non-ancestrial revisions

Marius Kruger amanic at gmail.com
Sat May 16 01:16:03 BST 2009


2009/5/13 Ian Clatworthy <ian.clatworthy at canonical.com>

> Ian Clatworthy has voted comment.
> Status is now: Semi-approved
> Comment:
> The behaviour is documented and by design: it starts at the end revision
> and walks the graph until it finds the start revision.


I apologise for my ignorance, I vaguely remember a discussion about this
when you made the changes.


> Please re-read the help for log.


thanks for the pointer, its been a while since I read what has now become a
book :) nice and complete.


> If there's a genuine use case for wanting filtering done in the way you
> expected, let me know.


I was just surprised that generating the graph produces different output
than not, and concerned that it may be an oversight. This was my way of
clarifying it, and to that end I'll submit tests for the designed behaviour
shortly.


> Otherwise, please reject this patch.


bb:reject


2009/5/11 John Arbash Meinel <john at arbash-meinel.com>
> As you can see it skips some revisions. After doing some debugging,
> I realised that it skips them because they are not ancestors of the
> end-revision.

If they aren't in the ancestry, why would they be displayed?

well to me it originally looked like:

F
|\
|E
| |
|D
|/
C
|
B
|
A

because of how log displays it.
thus I expected log A..D to show A,B,C,D

but it is actually:

F
|\
CE
| |
BD
|/
A

So it shows A,D

regards
marius
(Whew, I normally skip over e-mails with diagrams like above because they
require too much thinking, and now I make one. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090516/5dc4d673/attachment.htm 


More information about the bazaar mailing list