Duy Nguyen <pclo...@gmail.com> writes:
> On Fri, Feb 15, 2013 at 11:52 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> In the current code, we always check if a path is excluded, and when
>> dealing with DT_REG/DT_LNK, we call treat_file():
>> * When such a path is excluded, treat_file() returns true when we
>> are not showing ignored directories. This causes treat_one_path()
>> to return path_ignored, so for excluded DT_REG/DT_LNK paths when
>> no DIR_*_IGNORED is in effect, this change is a correct
>> * When such a path is not excluded, on the ther hand, and when we
>> are not showing ignored directories, treat_file() just returns
>> the value of exclude_file, which is initialized to false and is
>> not changed in the function. This causes treat_one_path() to
>> return path_handled. However, the new code returns path_ignored
>> in this case.
>> What guarantees that this change is regression free?
> If you consider read_directory_recursive alone, there is a regression.
> The return value of r_d_r depends on path_handled/path_ignored. With
> this patch, the return value will be different.
That is exactly what was missing from the proposed log message, and
made me ask "Do all the callers that reach this function in their
callgraph, when they get path_ignored for a path in the index,
behave as if the difference between path_ignored and path_handled
does not matter?" Your answer seems to be
- r-d-r returns 'how many paths in this directory match the
criteria we are looking for', unless check_only is true. Now in
some cases we return path_ignored not path_handled, so we may
return a number that is greater than we used to return.
- treat_directory, the only user of that return value, cares if
r-d-r returned 0 or non-zero; and
- As long as we keep returning 0 from r-d-r in cases we used to
return 0 and non-zero in cases we used to return non-zero, exact
number does not matter. Overall we get the same result.
I think all of the above is true, but I have not convinced myself
that r-d-r with the new code never returns 0 when we used to return
> It's a bit tricky. I'm not sure if I miss anything else.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html