How to make `hg diff` show whitespace changes?

[Sean Farley]

Matt Mackall <mpm at selenic.com> writes:

> On Thu, 2016-01-14 at 11:04 -0500, Matt Harbison wrote:
>> (cc: list)
>> 
>> On Thu, 14 Jan 2016 10:26:05 -0500, Noemi Millman
>> <noemi.millman at backstage.com> wrote:
>> 
>> > 
>> > Thanks, Matt!
>> > 
>> > Great call about the resource forks (and a facepalm moment for me!)I
>> > can confirm that that's the problem, since changing the default app to
>> > open a file without editing the file itself adds it to the list of
>> > mysteriously changed-yet-unchanged files.
>> > 
>> > I wonder why Mercurial recognizes resource fork changes but git doesn't?
>> 
>> It's been a few months since I looked into it, but IIRC, the python call
>> used to determine the file size sees both the data and resource forks.
>
> First, let's all agree that BeyondCompare devs should not fare well in the
> afterlife for adding resource forks to read-only files on Unix in 2015.
>
> Everything I can find suggests that stat(2) and os.stat ignore the resource fork
> for st_size (but include it in st_blocks, which we ignore). But we're actually
> using the special getdirentriesattr interface:
>
> https://www.selenic.com/hg/file/tip/mercurial/osutil.c#l483
>
> And it's complicated. But it looks like instead of ATTR_FILE_TOTALSIZE, we
> should be using ATTR_FILE_DATALENGTH:
> https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages
> _iPhoneOS/man2/getattrlist.2.html#//apple_ref/doc/man/2/getattrlist
>
> Please test this patch:
>
> diff -r 443848eece18 mercurial/osutil.c
> --- a/mercurial/osutil.c	Wed Jan 13 15:47:37 2016 -0600
> +++ b/mercurial/osutil.c	Thu Jan 14 12:20:28 2016 -0600
> @@ -458,7 +458,7 @@
> 	requested_attr.bitmapcount = ATTR_BIT_MAP_COUNT;
> 	requested_attr.commonattr = (ATTR_CMN_NAME | ATTR_CMN_OBJTYPE |
> 				ATTR_CMN_MODTIME | ATTR_CMN_ACCESSMASK);
> -	requested_attr.fileattr = ATTR_FILE_TOTALSIZE;
> +	requested_attr.fileattr = ATTR_FILE_DATALENGTH;
>
> 	*fallback = false;

I just applied this and ran tests on my mac with no obvious failures or
blow ups.