[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