[Bug 32526] uncommit -r off by one
Wouter van Heyst
larstiq at larstiq.dyndns.org
Thu Feb 23 00:20:47 GMT 2006
On Wed, Feb 22, 2006 at 06:09:24PM -0600, John Arbash Meinel wrote:
> James Blackwell wrote:
> > Public bug reported:
> > https://launchpad.net/malone/bugs/32526
> >
> > Affects: bzr (upstream)
> > Severity: Normal
> > Priority: (none set)
> > Status: Unconfirmed
> >
> > Description:
> > As of revision 1543 runnin "bzr uncommit -r revno" is off by one
> > revision. If one wants to return to revsision "1528" then one needs to
> > specify revision "1529"
> >
>
> That is actually the design. 'uncommit -r' is saying 'uncommit this
> revision', versus 'revert' which is saying 'revert *to* this revision'.
The current behaviour makes sense to me, 'bzr uncommit -r 0' would be
funny. I do not feel strongly about it though.
>
> Now, I can agree that the distinction is minor. And I've found myself
> saying "uncommit *to* this revision". So we may want to change the
> semantics of the command.
>
> I'm sending this to the mailing list so that we can have a discussion
> about what 'uncommit -r' should mean.
Related, there has been at least one request for revert to mean 'revert
_only this_ revision', instead of revert _to_ this revision (taking
whatever came after it with it). In my mind popping revisions off the
stack is the right thing to do, otherwise ending up with a situation
that has never existed in the past. Am I alone in this?
Wouter van Heyst
More information about the bazaar
mailing list