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

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2016, 23:22 UTC
Message-ID: <xmqq37pw84zq.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqq7ff885hj.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

> Stefan Beller <sbeller@google.com> 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?