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

[Martin von Zweigbergk]

On Thu Dec 04 2014 at 9:15:30 AM Martin von Zweigbergk <
martinvonz at google.com> wrote:

> On Wed Dec 03 2014 at 10:27:39 PM Matt Harbison <mharbison72 at gmail.com>
> wrote:
>
>> 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 think anypats() is currently used for checking whether optimization are
> possible, so we probably don't want to change that method.
>
>
>>   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
>>
>
> Does it seem fair to say that we want to use relative paths in the UI in a
> few cases (addremove, status, locate) if the user has not restricted the
> paths in any way? If it is, it seems like we would need a flag on the
> matcher that is disconnected from what the matcher actually matches. That
> might be your _anyfiles, but modified to be "bool(patterns or include or
> exclude)" and maybe renamed to _userelativepathsinui (but shortened). *sigh*
>

But in that case it seems better to just keep the knowledge outside of
matcher. Does the need to pass it around in the matcher arise from subrepo
use cases? I guess I didn't get that part from your patches.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141204/edd8d05a/attachment.html>