[PATCH] addremove: print relative paths when called with -I/-X

[Matt Harbison]

On Thu, 04 Dec 2014 00:35:11 -0500, Martin von Zweigbergk  
<martinvonz at google.com> wrote:

> On Wed Dec 03 2014 at 9:11:19 PM Matt Harbison <matt_harbison at yahoo.com>
> wrote:
>
>> On Tue, 02 Dec 2014 07:02:29 +0000, Martin von Zweigbergk wrote:
>>
>> > mpm, I see you have a lot of patches in flight. If you agree with this
>> > patch, you may want to pick it before the other Matt's patches, and
>> instead
>> > make the poor guy send a V3.
>> >
>> > Matt, I didn't look past the first 6 or so patches. Did the anyfiles()
>> > method end up being used anywhere else, or would this patch remove the
>> need
>> > for it completely?
>> >
>> > On Mon Dec 01 2014 at 9:56:26 PM Martin von Zweigbergk <
>> > martinvonz at google.com> wrote:
>> >
>> >> # HG changeset patch
>> >> # User Martin von Zweigbergk <martinvonz at google.com>
>> >> # Date 1417499312 28800
>> >> #      Mon Dec 01 21:48:32 2014 -0800
>> >> # Node ID 0ec94796e8c2d5c142976edb49c911a92341b109
>> >> # Parent  19ebd2f88fc77282efe724b30de8750f79771e8f
>> >> addremove: print relative paths when called with -I/-X
>> >>
>>
>> So I rebased my V2 series on top of this, and it changed the tests on  
>> me.
>> Specifically the test I tried was basically:
>>
>>         $ hg init repo
>>         $ mkdir repo/dir
>>         <create various files>
>>         $ cd repo/dir
>>         $ hg addremove ..
>>
>> This prints out absolute files instead of relative, unlike before.  I  
>> put
>> some prints in match, and what happens (in my real test) is '..' gets
>> normalized to:
>>
>>         [('relpath', '.hglf')]"
>>
>> match._anypats() doesn't consider 'relpath' to be a pattern, so it  
>> returns
>> None, and match.anypats() therefore returns False.  Maybe it should be  
>> OR'd
>> with the fact that the pattern parameter is not empty?  I didn't run the
>> tests to see if that breaks anything.  (I'm not sure why it didn't also
>> list the directory I was in as a relpath too.)
>>
>
> Without having spent much thought to it, does 'not m.always()' work  
> better?
> I ask because that's what it seemed like status and locate wanted when I
> checked. It's just mostly the same for addremove since exact() was  
> already
> discounted.

I'm not sure.  My concern is that largefiles creates matchers with the  
_always field set to False.  See composenormalfilematcher() in  
largefiles/overrides.py.  I haven't sent the second half of the series  
yet, but that matcher will be passed to this code, and it basically  
eliminates the conditional when it is hardcoded to False.  It makes sense  
that the largefiles matcher is hardcoded, since it is excluding some  
files.  So this idea seems close, but a step in the wrong direction.

It seems surprising to me that a list called patterns can be given to the  
matcher, and then the matcher reports that no patterns were given.  Maybe  
it is just an unfortunate similarity in the names, but it seems like that  
needs to be fixed (or better documented what the differences are).

--Matt