bug in patch.diffopts()?

Douglas Philips dgou at mac.com
Fri Jul 18 00:16:43 CDT 2008


I'm just starting to poke around in the Mercurial internals, so I  
wanted to ask the list if I've missed something before I file a bug  
report, since my understanding is pre-NooB.

I went down this path because I was trying to figure out why the  
notify extension wasn't obeying the .hgrc diff options. First off,  
thanks for bundling this extension and thanks to Vadim Gelfer for  
writing it.

So I looked into the code for hgext/notify.py, and it looks as if it  
calls patch.diff()
and patch.diff() takes an 'opts' optional parameter, which the notify  
extension does not provide.

If patch.diff() gets a None for the 'opts' parameter, it uses  
mdiff.defaultopts.
mdiff.defaultopts is initialized to a bunch of defaults that appear to  
be hard coded. The obvious grep for mdiff.defaultopts and grep  
defaultopts don't seem to find any code that might redefine the values  
in defaultopts before patch.diff() grabs 'em.

So it appears that all I need to do is pass in an  
opts=patch.diffopts(self.ui) and sure enough now the notify extension  
is obeying the [diff] options in the .hgrc.

Here is the point at which I think I have found a bug:
When looking at patch.diffopts(), it defines its own little helper:  
get()
and that little get() uses ui.configbool().
At the end of patch.diffopts() it requests the unified 'parameter'  
from the get() helper, which can very well read a unified value from  
the hgrc file and stuffs it into the context slot of the diffopts it  
is building.
However, when I looked at how the mdiff.diffopts object is used, the  
context slot is expected to be a number, not a boolean.

So, is there some boolean -> number python casting magic at work, but  
the net of the net is that I cannot use the '[diff]' part of my .hgrc  
to set the number of lines of context. I can set to some value which  
can convert to a bool and then will be converted back to either 0 or 1.

Or I'm just thoroughly confused, it is late in this time zone and I've  
never looked inside Mercurial sources before...

Thanks for any help, insight, pointers, hints, etc.
     --Doug



More information about the Mercurial-devel mailing list