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

Martin von Zweigbergk martinvonz at google.com
Tue Dec 2 17:41:23 CST 2014


My patch is now in 'default'. I take that to mean that I should go ahead
and change the other cases (locate and status) so they also use relative
paths whether '<pattern>' or '-I <pattern>' is used. I'll start working on
those soon.

On Tue Dec 02 2014 at 8:21:23 AM Martin von Zweigbergk <
martinvonz at google.com> wrote:

> On Tue Dec 02 2014 at 7:30:25 AM Matt Harbison <mharbison at attotech.com>
> wrote:
>
>> 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?
>>
>
> Thanks for checking. Yes, locate even has a test for the absolute path,
> although it's not very clear if that was the intent. Maybe there's a reason
> that the two forms should behave differently. I suppose one could say that
> -I/-X should have as little effect as possible on the command and just
> restrict the set of files acted on. I'll wait for comments from mpm or
> someone else who remembers how to view -I/-X before I send more patches.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141202/2bfe1e3d/attachment.html>


More information about the Mercurial-devel mailing list