[PATCH 3 of 4 V2] largefiles: align the output messages for a removed file with core methods

Matt Harbison mharbison72 at gmail.com
Tue Dec 30 19:53:30 CST 2014


On Tue, 30 Dec 2014 20:44:28 -0500, Martin von Zweigbergk  
<martinvonz at google.com> wrote:

> On Tue Dec 30 2014 at 4:56:13 PM Matt Harbison <mharbison72 at gmail.com>
> wrote:
>
>> diff --git a/tests/test-largefiles-misc.t b/tests/test-largefiles-misc.t
>> --- a/tests/test-largefiles-misc.t
>> +++ b/tests/test-largefiles-misc.t
>> @@ -257,21 +257,55 @@
>>    $ echo 'normal file' > subrepo/normal.txt
>>    $ touch large.dat
>>    $ mv subrepo/large.txt subrepo/renamed-large.txt
>> -  $ hg -R subrepo addremove --dry-run
>> -  removing large.txt
>> -  adding normal.txt
>> -  adding renamed-large.txt
>> +  $ hg addremove -S --dry-run
>> +  adding large.dat as a largefile
>> +  removing subrepo/large.txt
>> +  adding subrepo/normal.txt
>> +  adding subrepo/renamed-large.txt
>> +  adding large.dat
>>
>
> Do we want both  "adding large.dat as a largefile" and "adding large.dat"
> printed? Is that caused by this patch? What would have happened before  
> this
> patch?

We don't want that, but it isn't caused by this patch.  I forgot to copy  
parts of the commit message from the original test only patch mpm  
dropped.  The fix may be as simple as fixing composenormalmatcher() to not  
match against configured largefile patterns, but I haven't tried it, and  
the --normal option might mean that won't work.

This was the snippet that I forgot to copy over:

There is also an issue where dryruns appear to add a file as both a large  
and a
normal file.  This is cosmetic though- it doesn't happen without  
--dry-run.  The
reason is that the largefiles are added first, and then the normal files  
are
added.  In a regular run, the largefile isn't returned by
scmutil._interestingfiles(), because it has been stripped out of the  
matcher by
overrides.composenormalfilematcher().  But that doesn't happen in a dryrun
because the stripping only happens if there is a standin, so  
scmutil.addremove()
thinks the largefile candidate is an untracked file.

--Matt


More information about the Mercurial-devel mailing list