Code review comment for lp:~amanica/bzr/log_returns_too_much
Revision history for this message
| Marius Kruger (amanica) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
> Since this is breaking the compatibility, as long as it is a step
> towards where we want to be for log, I'm happy to see it land. Though I
> would probably wait for 1.18.
>
> (I don't really want to see us break the meaning of 'bzr log -r X..Y'
> two times in two releases back-to-back.)
I'm busy implementing what you suggested in the previous merge-request-
So if you want minimum disruption, you may defer landing this until I'm done with that.
They have some overlap and they cancel each other out a bit.
The following branch more or less implements your suggestions,
but I'd like some feedback before I go all the way to fix all the tests and update all the documentation etc: lp:~amanica/bzr/320119-log_exclusive_lower_bound/
I have 2 questions between your suggestions (marked with ending '?'):
1) "bzr log -r 10" should show just the revision 10 (https:/
* I assume we should still allow "bzr log -n0 -r 10" to show the parents!?
(when a range is given, we never show the parents any more as per Bug #325618)
2) "bzr log -c 10" should show all the changes that were merged into 10 sounds like a must have feature otherwise its really difficult to figure out what happened (I resorted to bzr explorer & qlog to be able to successfully navigate this) bzr diff seems to work that way too.
* This just becomes an alias for "bzr log -n0 -r 10". Do we need to retain it in that case? I assume so.
3) "bzr log -r 9..11" should *not* show the revision for 9 (https:/
These changes break a lot of tests, I intend to only change the minimum
to get them to pass.
[1] https:/