Annotate bug ?

John Arbash Meinel john at
Fri Jun 16 18:48:21 BST 2006

Hash: SHA1

Olaf Conradi wrote:
> On Wed, May 17, 2006 at 11:24:43PM +0200, Olaf Conradi wrote:
>> On Wed, May 17, 2006 at 09:23:59PM +0200, Goffredo Baroncelli wrote:
>>> Hi all,
>>> If I do on a "" repository
>>> $ bzr annotate -r \ 
>>> 	revid:robertc at \
>>> 	bzrlib/
>>> I get
>>> bzr: ERROR: Branch < object at 
>>> 0x2aaaad4b92d0> has no revision 
>>> john at
>> Congratulations, you found the ghost revisions of 2005-07-11.
>>  -Olaf
> OK, fixed it, somehow the indentation got misaligned.
> I'll put it in my ancestry branch, with a test case.
> But for your convenience I already attached the patch for you to try.
>  -Olaf

I tried pretty hard to create a test case for this. But it requires
creating a Knit entry which says that a line was created by a revision
which isn't actually present.
I tried just creating a ghost merge, but it turns out that the standard
commit code just attributes the changes to the new commit. (Which makes
sense, since it can't tell that they came from the ghost).

So I'm tempted to punt and just merge the fix, rather than having a test
case for it.

I would really like a test case for it, but it takes a lot of internal
hacking, since the UI is designed to prevent these sort of edge cases
from occurring.

I honestly don't know how the original code was able to attribute the
changes to a ghost. (Which is what we now have in

The only thing I can think to do, is to build up the branches, and then
break the api layering and call '_add_raw_records()' directly.

I don't know the internals of that code terribly well, though, so maybe
there is an easier way.

I know Martin gave a +1 to this, but it would be nice if we had a test
so it doesn't regress.

Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list