[PATCH STABLE] largefiles: fix commit of a directory with no largefile changes (issue4330)

[Matt Harbison]

On Tue, 20 Jan 2015 16:47:14 -0500, Matt Mackall <mpm at selenic.com> wrote:

> On Sun, 2015-01-18 at 19:49 -0500, Matt Harbison wrote:
>> On Sun, 18 Jan 2015 19:29:51 -0500, Matt Mackall <mpm at selenic.com>  
>> wrote:
>>
>> > On Sun, 2015-01-18 at 16:28 -0500, Matt Harbison wrote:
>> >> # HG changeset patch
>> >> # User Matt Harbison <matt_harbison at yahoo.com>
>> >> # Date 1421612140 18000
>> >> #      Sun Jan 18 15:15:40 2015 -0500
>> >> # Branch stable
>> >> # Node ID c27d3218ffa9096bb0812e30d5e66a05b88a92d6
>> >> # Parent  cb21ffd4b6c7e6572e6ab33fb3dfb18949b1ecd7
>> >> largefiles: fix commit of a directory with no largefile changes
>> >> (issue4330)
>> >
>> > This is queued for stable, thanks.
>> >
>>
>> Is the OS specific status behavior expected, w.r.t. whether match() is
>> called when no directories are named?
>
> Nope. At a guess, the Windows version of the behavior is probably the
> unintended one.
>

For the benefit of anybody searching the archives in the future, this  
isn't OS dependent- it is filesystem dependent.  I messed up the Linux  
vfat setup, and didn't actually run it on a vfat fs.  When I did, it  
exhibited the same behavior as Windows.

What happens is that in dirstate.walk(), running on a case insensitive  
filesystem forces step 3 to run, which passes every single file in  
dirstate to the matcher's match function.  Any matches are returned from  
walk().  If there are no directories in the matcher's file list, step 3 is  
skipped on case sensitive filesystems.  Thus the need to add '.' to force  
the full walk.

The code as committed is correct, but I'll update the comment after  
default is reopened.

--Matt