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

[Martin von Zweigbergk]

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*

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141204/26abea22/attachment.html>