List of uncommits

Chris McCormick chris at
Tue May 8 07:30:19 UTC 2012

Hi John,

On 05/08/2012 03:07 PM, John Arbash Meinel wrote:
> Hash: SHA1
> ...
>>> You can restore the old tip by running: bzr pull . -r
>>> revid:john at
>> Yes, that's normally the case, and the expected behaviour, however
>> in this case what happened was I ctrl-C'ed the operation before it
>> had finished uncommitting the local branch but after it had
>> finished uncommitting the bound (remote) branch. Maybe this is a
>> bug and I should report it? It means the two repositories were left
>> out of sync and there was no message printed, despite the fact the
>> operation had been successful on the remote branch. I am not sure
>> what the fix would be though. Maybe to print something to this
>> effect letting the user know that the operation has been completed
>> on the remote (bound) branch but not the local one?
>> Another possible fix would be for me to not work when sleep
>> deprived. :)
>> Cheers,
>> Chris.
> If there is a race where there is a branch tip changing before it logs
> the fact, then it should be a bug. However, looking at the code I see:
>          mutter('Uncommitting from {%s} to {%s}',
>                 last_rev_id, rev_id)
>          uncommit(b, tree=tree, dry_run=dry_run, verbose=verbose,
>                   revno=revno, local=local, keep_tags=keep_tags)
> So it should be written to .bzr.log even though it hasn't written it
> to the screen yet.
> bzr heads --dead
> is a fine way to do it, but I think I have about 50+ dead heads in my
> repository. Vs the fairly recent line in .bzr.log.
> If you have a chance to see if that line is in your .bzr.log, then I'm
> happy enough and we don't need a bug.

It certainly is!

1.373  Uncommitting from 
{chris at} to 
{chris at}

And then the KeyboardInterrupt traceback.

I am not sure if I am a typical user or not but I would not have thought 
to check ~/.bzr.log - I will from now on though!

Thanks for all the help.




More information about the bazaar mailing list