[issue289] mq should create & maintain diffstats in patches

[Jeremy Fitzhardinge]

Chris Mason wrote:
> I do like the patch, but I'm curious to see if it is measurably slower.  
> str.startswith is faster than re in general, so I'm somewhat worried about 
> this.
>   
I'll do some tests, but it seems to me that it wouldn't make much 
difference.  Assuming that most of a patch file is actual diff chunks, 
the time to parse the comment shouldn't factor into it much.  The 
current parser does scan the whole file, but it could stop as soon as it 
gets to the first diff chunk.  I'll do some tests.

> Also, it makes sense to add an hgrc option to diffstat on qrefresh.  Or maybe 
> I should implement the hg qedit command people have been asking for to pop up 
> the patch in $EDITOR.  We could do hg qedit -d to auto stat it.
>   
I don't think that's necessary.  The current behaviour is to update a 
diffstat if present, and do nothing if not.  There's no way to add a 
diffstat to an existing patch without pasting it in manually, but that's 
pretty simple; I was considering adding some logic to treat:

    --
    @DIFFSTAT

(or something) as a diffstat placeholder which would be updated by 
qrefresh.  I was also thinking about adding a qdiffstat command to add 
(or update) a diffstat to the current patch, but it was looking a bit 
more fiddley than I would have liked, and it isn't strictly necessary.  
qedit -d seems reasonable to me though.

I'm assuming it never makes sense to leave a diffstat unmodified in a 
patch comment.  I can't think of any uncontrived reason why that 
wouldn't be true.

> Since your fingers are in the code, mq and hg import use different diff 
> parsers, which is not a good idea.  Can I talk you into joining them?
>   
I'll take a look at it.  I was thinking of changing the readheader() 
function to return something a bit more structured than a tuple anyway.