Any way to fake "hg annotate -w"?

[Ali Saidi]

You could modify the convert extension to replace all the tabs with  
spaces in a hg -> hg conversion.  That way you would keep all the  
revision information the same. Everyone using the repo would have to  
get a a new copy of it, but otherwise it's reasonably painless.

Ali

On Jun 27, 2008, at 12:11 AM, Rob Landley wrote:

> On Saturday 21 June 2008 12:30:17 Matt Mackall wrote:
>> On Wed, 2008-06-18 at 20:24 -0500, Rob Landley wrote:
>>> I can tell hg diff to ignore whitespace-only changes to lines, but I
>>> can't find a way to make hg annotate do the same.
>>>
>>> Any suggestions?
>>
>> No. This is actually quite tricky, and our diff algorithm sometimes  
>> gets
>> it wrong too.
>
> Hmmm, pondering this further:
>
> I have a project with a tabstop of 4, and Ubuntu's continuing quest  
> to make vi
> unusable broke parsing the "/* vi: set ts=4 :*/" comments at some  
> point
> between 6.10 and 7.10.  (And that's _after_ doing
> the "rm /etc/vim/vimrc.tiny; ln -s vimrc /etc/vim/vimrc.tiny" you  
> need to do
> to restore minimal usability in vim in Ubuntu.)  Rather than fight  
> with it,
> I'd like to just do one big checkin converting all the project's  
> indents to 4
> spaces per tab via sed, but that would make "hg annotate" essentially
> unusable for quite a while.
>
> I'm aware that whitespace can be semantically important.  (Not just in
> python/make/kconfig, but in any language that does token parsing to  
> figure
> out where symbols begin and end.)  That said, what "diff -w" is  
> asking for is
> to ignore all whitespace.  I.E. compare the output of "sed 's/[ \t]// 
> g'" on
> both files.  Yes, the result can merge together semantically  
> different lines
> and makes them compare identical, but that's what the user _asked_  
> for.
> Ignore all whitespace, treat the line as if it had no whitespace in  
> it at
> all.
>
> You can't do better than that without understanding the contents of  
> the file
> (since "if(x)" and "if (x)" are the same line in C, while spaces in  
> quoted
> strings matter, but there's no way to know that without  
> understanding C).
> But you don't _have_ to do better than that.  It's often going to miss
> important changes in python, occasionally it'll do so in C, but  
> it'll miss
> them in a simple, straightforward and understandable way.
>
> Is this the difficulty you referred to, or is there more to it than  
> that?
>
> Rob
> -- 
> "One of my most productive days was throwing away 1000 lines of code."
>  - Ken Thompson.
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>