Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree

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

 



On Wed, Oct 10, 2012 at 12:33 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes:
>
>> On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>> Jeff King <peff@xxxxxxxx> writes:
>>>
>>>> I think we just need to have callers of grep_source_init provide us with
>>>> the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is
>>>> where the information is lost.
>>>
>>> Yes.  I agree that is the right approach.
>>
>> Passing full path this way means prepare_attr_stack has to walk back
>> to top directory for every files (even in the same directory). If
>> .gitattributes are loaded while git-grep traverses the tree, then it
>> can preload attr once per directory. But Jeff's approach looks
>> simpler.
>
> Why can't you do both?  That is, to build a full path as you
> descend, and read per-directory .gitattributes as you go?

Hm... I need to check attr.c code but I think it means read
.gitattributes and prepare attr stack in builtin/grep.c (where we
traverse trees) and actually check the attribute in
grep_source_load_driver(), much further down the call stack. I'm not
sure how we can pass the prepared attr stack down to
grep_source_load_driver().
-- 
Duy
--
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]