Comment 3 for bug 286834

So... I think this is actually triggered from doing:

touch foo
bzr add foo
rm foo

bzr gcommit

  File "C:\Users\jameinel\dev\bzr\plugins\gtk\diff.py", line 659, in iter_changes_to_status
    assert kinds[0] is not None
AssertionError

I can reliably trigger it using that sequence. The problem is that we have a versioned file which appears to be missing. So the 'source' kind is None because it was just added, but the target kind is None because the file has been removed.

I don't know the correct fix for bzr-gtk, but in the mean-time you can do "bzr rm foo" to fix this.

However, finding out what "foo" is actually hanging is a bit difficult, because it won't show with 'bzr status" (because it sees (None, None) as no change.)

You *can* do: bzr commit -m "find the bogus file"

Which will include a line:
missing foo

And then if you don't want that commit, you can do:
bzr uncommit
bzr rm foo

(Actually in my testing here, doing 'bzr commit --local' caused an abort because there were no effective changes, and cleaned out the unused entry.)