Am 15.02.2013 20:32, schrieb Junio C Hamano:
> Duy Nguyen writes:
>
>> On Fri, Feb 15, 2013 at 11:52 PM, Junio C Hamano 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, t
On Sat, Feb 16, 2013 at 2:32 AM, Junio C Hamano wrote:
>> 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
Duy Nguyen writes:
> On Fri, Feb 15, 2013 at 11:52 PM, Junio C Hamano 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
On Fri, Feb 15, 2013 at 11:52 PM, Junio C Hamano 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 c
Nguyễn Thái Ngọc Duy writes:
> read_directory() (and its friendly wrapper fill_directory) collects
> untracked/ignored files by traversing through the whole worktree (*),
> feeding every entry to treat_one_path(), where each entry is checked
> against .gitignore patterns.
>
> One may see that tr
read_directory() (and its friendly wrapper fill_directory) collects
untracked/ignored files by traversing through the whole worktree (*),
feeding every entry to treat_one_path(), where each entry is checked
against .gitignore patterns.
One may see that tracked files can't be excluded and we do not
6 matches
Mail list logo