histedit todo

[Mads Kiilerich]

I haven't used histedit but worked a bit on the test failures it introduced.

There is in my opinion still some things to do. Here is a badly 
researched list, covering both minor nit-picking and what might be more 
important issues:

There should be some generic help for the extension - some explanation 
of what it is without assuming git knowledge, a description of what 
problem it solves and how it solves it and perhaps a small usage example.

The UI messages should be reviewed, it should use the right (lower) 
casing and aborts should be single line with a hint. That should be 
cleaned up before translators start translating.

'should' in a note and some debug messages sounds to me like something 
that is followed by a 'but' and isn't done anyway. The usual style is to 
just say what we are doing.

There seems to be some inconsistency in the use of 'rules', 'commands', 
'EDITED' and 'editedhistory' in the code and tests. Consistent 
terminology might help adoption and make it more maintainable. If the 
name of the command line should be changed then it would be better to do 
it now than later.

Some variables with unfortunate naming might make maintenance harder: 
created/created_ and replaced/replaced_.

It seems like an opener should be used for histedit-last-edit.txt - and 
perhaps also in other places.

assertions are used. Some of them are so verbose that they look like 
something the user can hit and thus should have been an abort.

hexshort and node.hex(n)[:12] - should probably use node.short instead?

The tests introduce a magic missing-comment.hg - it should have a 
descriptive name and a description of how it was created ... or be 
created on the fly.

There are some TODO's in the code.

This introduces the first use of pickle as storage format. Changing the 
format later on could annoy users. Is that a format we want to commit 
ourself to? What are the security implications of someone browsing some 
untrusted repo with the extension enabled?

/Mads