[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