Re: [RFC PATCH] pathspec: get non matching arguments without reporting.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> When giving more than just pathspec arguments (e.g. submodule labels),
>> we need a way to check all non-matching arguments for the pathspec parsing
>> if these are the submodule labels or typos.
>>
>> This patch prepares for that use case by splitting up `report_path_error`
>> into a new checking function `unmatched_pathspec_items` and a
>> reporting callback.
>
> I seem to recall that there is a longstanding plan to move the
> "seen[]" array that is separate and outside from the pathspec
> structure into the pathspec structure.  Wouldn't that be a more
> sensible approach to solve the same thing?

Even with such a refactoring, the need to split the "preprocessing"
(mainly "dedup") still remains if you want to silence this codepath,
so I think this is OK from pathspec/dir.c point of view.

But I do not agree with the first paragraph at all.  You'd be using
separate syntax like '*label', ':name', etc. for the purpose of
enumerating submodules, so instead of blindly passing argv[] to
pathspec code, I expected you to do a preprocessing of argv[]
upfront, sifting them into three bins (labels, names and paths), and
giving only the last ones to the pathspec machinery.

And if you did that, report_path_error() would never have to worry
about "ah, this thing does not exist in the working tree or in the
index but that is natural because it is a submodule label" at all,
no?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]