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

Matt Harbison mharbison at attotech.com
Tue Dec 2 09:23:31 CST 2014


Martin von Zweigbergk <martinvonz <at> google.com> writes:

> 
> 
> 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?

I'll check when I get home, but I doubt it.  The other 8 or so patches that
I didn't send yet deal with making the largefiles methods print the path
correctly.  I was puzzled too why the discrepancy with how the path was
printed with pats vs -I/-X, but superseded v1 because anypats() caused an
existing test to change, and I figured I'd have a better chance of getting
this through if there weren't subtle side effect changes like that.

A grep for '\(pats and' shows that annotate, locate and status use a similar
pattern, so maybe you want to fix those too?  I didn't dig deeper to see if
the pattern occurs with other names.  No clue why other commands that allow
patterns (like add and forget) don't also do this too- they just print
match.rel().

FYI, the other patches I'm waiting to send change match.rel() to internally
call path.join(), and then I added a match.abs() to do similar.  I didn't
need it, but got to thinking later, maybe we want a match.show(f) or
something similar to encapsulate this rel vs abs logic, so as not to clutter
up the caller's code?  OTOH, maybe this pattern isn't used enough to justify it.

I do agree with the reasoning behind this patch though, so I don't mind
sending a v3 if I have to.

--Matt





More information about the Mercurial-devel mailing list