git grep failure?

git grep failure?

[Wayne Walker]

I use git grep constantly.  Today it failed for me. It isn't looking
at all the files for some reason.  Am I somehow missing something?

midsizeschools@ut:~/tams (master u= origin/master)$ git ls-files | wc
    254     254   10062
midsizeschools@ut:~/tams (master u= origin/master)$ git grep -l . | wc
    250     250    9938
midsizeschools@ut:~/tams (master % u= origin/master)$ git grep -l . |
sort > b
midsizeschools@ut:~/tams (master % u= origin/master)$ git ls-files |
sort > a
midsizeschools@ut:~/tams (master % u= origin/master)$ diff a b
26,27d25
< app/models/tars_attendee.rb
< app/models/tars_district_registration.rb
144d141
< nbproject/private/config.properties
156d152
< public/favicon.ico

# git knows about the file:
~/tams (master u= origin/master)$ git ls-files | grep
app/models/tars_district_registration.rb
app/models/tars_district_registration.rb

# the string is found by grep in the file:
~/tams (master u= origin/master)$ grep accepts_nested_attributes_for
app/models/tars_district_registration.rb
accepts_nested_attributes_for :tars_attendees, :allow_destroy =>
false, :reject_if => proc { |attrs| attrs.all? { |k, v| v.blank? } }

# but git grep doesn't find the file????
~/tams (master u= origin/master)$ git grep accepts_nested_attributes_for
~/tams (master u= origin/master)$

# git version is reasonably new - not my server, can't upgrade it
~/tams (master u= origin/master)$ git --version
git version 2.19.2

--
Wayne Walker
lwaynewalker@gmail.com

Re: git grep failure?

[Wayne Walker]

Please ignore my previous email.  I have found what causes the
problem.  The files that it isn't matching against are symlinks (known
to git, but git grep apparently doesn't grep what they point to.

Sorry to have wasted anyone's time.

Wayne Walker

git grep failure?

[Randy Dunlap]

Hi,

If I apply the patch at
https://lore.kernel.org/linux-doc/c5bb61cf789df1ecb32facc29df9749987c7ddfc.1773346620.git.ljs@kernel.org/

Subject: [PATCH 02/15] mm: add documentation for the mmap_prepare file operation callback

to the Linux kernel tree (e.g., linux-next-20260316), it applies cleanly.

I noticed a typo in the patch ("struct vma_area_desc" should be
"struct vm_area_desc"). When I run
$ git grep vma_area_desc
the output is empty.

Is this expected? (but not by me :)

thanks.
-- 
~Randy

Re: git grep failure?

[Jeff King]

On Wed, Mar 18, 2026 at 04:28:17PM -0700, Randy Dunlap wrote:

> If I apply the patch at
> https://lore.kernel.org/linux-doc/c5bb61cf789df1ecb32facc29df9749987c7ddfc.1773346620.git.ljs@kernel.org/
> 
> Subject: [PATCH 02/15] mm: add documentation for the mmap_prepare file operation callback
> 
> to the Linux kernel tree (e.g., linux-next-20260316), it applies cleanly.
> 
> I noticed a typo in the patch ("struct vma_area_desc" should be
> "struct vm_area_desc"). When I run
> $ git grep vma_area_desc
> the output is empty.
> 
> Is this expected? (but not by me :)

I applied the patch and git-grep does produce one line of output (the
instance added by the patch).

Two possible differences:

  - are you sure the patch application succeeded?

  - are you in a different subdirectory? By default git-grep narrows its
    search to your current working directory and its subdirectories. So
    if you are in arch/ or something, it would not find the result in
    Documentation/. You can do:

      git grep vma_area_desc :/

    to search from the root of the project.

-Peff

Re: git grep failure?

[Randy Dunlap]

On 3/18/26 5:38 PM, Jeff King wrote:
> On Wed, Mar 18, 2026 at 04:28:17PM -0700, Randy Dunlap wrote:
> 
>> If I apply the patch at
>> https://lore.kernel.org/linux-doc/c5bb61cf789df1ecb32facc29df9749987c7ddfc.1773346620.git.ljs@kernel.org/
>>
>> Subject: [PATCH 02/15] mm: add documentation for the mmap_prepare file operation callback
>>
>> to the Linux kernel tree (e.g., linux-next-20260316), it applies cleanly.
>>
>> I noticed a typo in the patch ("struct vma_area_desc" should be
>> "struct vm_area_desc"). When I run
>> $ git grep vma_area_desc
>> the output is empty.
>>
>> Is this expected? (but not by me :)
> 
> I applied the patch and git-grep does produce one line of output (the
> instance added by the patch).
> 
> Two possible differences:
> 
>   - are you sure the patch application succeeded?

'git apply filename.patch' succeeded AFAICT. git status shows one
untracked file (the one that is added by the patch).
Do I need to do 'git commit' also?

>   - are you in a different subdirectory? By default git-grep narrows its
>     search to your current working directory and its subdirectories. So
>     if you are in arch/ or something, it would not find the result in
>     Documentation/. You can do:
> 
>       git grep vma_area_desc :/
> 
>     to search from the root of the project.

I'm running 'git grep' from the top-level directory of the
kernel source tree.

thanks.
-- 
~Randy

Re: git grep failure?

[Junio C Hamano]

Randy Dunlap <rdunlap@infradead.org> writes:

> On 3/18/26 5:38 PM, Jeff King wrote:
>> On Wed, Mar 18, 2026 at 04:28:17PM -0700, Randy Dunlap wrote:
>> 
>>> If I apply the patch at
>>> https://lore.kernel.org/linux-doc/c5bb61cf789df1ecb32facc29df9749987c7ddfc.1773346620.git.ljs@kernel.org/
>>>
>>> Subject: [PATCH 02/15] mm: add documentation for the mmap_prepare file operation callback
>>>
>>> to the Linux kernel tree (e.g., linux-next-20260316), it applies cleanly.
>>>
>>> I noticed a typo in the patch ("struct vma_area_desc" should be
>>> "struct vm_area_desc"). When I run
>>> $ git grep vma_area_desc
>>> the output is empty.
>>>
>>> Is this expected? (but not by me :)
>> 
>> I applied the patch and git-grep does produce one line of output (the
>> instance added by the patch).
>> 
>> Two possible differences:
>> 
>>   - are you sure the patch application succeeded?
>
> 'git apply filename.patch' succeeded AFAICT. git status shows one
> untracked file (the one that is added by the patch).
> Do I need to do 'git commit' also?

"git apply filename.patch" or "git apply --index filename.patch"?
The former will leave the new file unknown to "git", so "git grep"
would not look into it.

>>   - are you in a different subdirectory? By default git-grep narrows its
>>     search to your current working directory and its subdirectories. So
>>     if you are in arch/ or something, it would not find the result in
>>     Documentation/. You can do:
>> 
>>       git grep vma_area_desc :/
>> 
>>     to search from the root of the project.
>
> I'm running 'git grep' from the top-level directory of the
> kernel source tree.
>
> thanks.

Re: git grep failure?

[Jeff King]

On Wed, Mar 18, 2026 at 09:42:23PM -0700, Randy Dunlap wrote:

> > I applied the patch and git-grep does produce one line of output (the
> > instance added by the patch).
> > 
> > Two possible differences:
> > 
> >   - are you sure the patch application succeeded?
> 
> 'git apply filename.patch' succeeded AFAICT. git status shows one
> untracked file (the one that is added by the patch).
> Do I need to do 'git commit' also?

Ah, I see. I used "git am" to apply the patch, which made a commit using
the email as the commit message.

As Junio noted, "git apply" by itself will not mark the file as tracked.
You would need to "git add" it, at which point git-grep would start
looking at it (since it only looks at tracked files). And then "git
commit" if you actually want a commit.

But at that point, you probably want to be using "git am", unless you
don't want to use the sender's commit message for some reason. (Though
even if that is the case, I'd probably use "git am" and then "git commit
--amend" to tweak it).

-Peff

Re: git grep failure?

[Randy Dunlap]

On 3/19/26 8:53 AM, Jeff King wrote:
> On Wed, Mar 18, 2026 at 09:42:23PM -0700, Randy Dunlap wrote:
> 
>>> I applied the patch and git-grep does produce one line of output (the
>>> instance added by the patch).
>>>
>>> Two possible differences:
>>>
>>>   - are you sure the patch application succeeded?
>>
>> 'git apply filename.patch' succeeded AFAICT. git status shows one
>> untracked file (the one that is added by the patch).
>> Do I need to do 'git commit' also?
> 
> Ah, I see. I used "git am" to apply the patch, which made a commit using
> the email as the commit message.
> 
> As Junio noted, "git apply" by itself will not mark the file as tracked.
> You would need to "git add" it, at which point git-grep would start
> looking at it (since it only looks at tracked files). And then "git
> commit" if you actually want a commit.
> 
> But at that point, you probably want to be using "git am", unless you
> don't want to use the sender's commit message for some reason. (Though
> even if that is the case, I'd probably use "git am" and then "git commit
> --amend" to tweak it).

OK, thanks to you and Junio for explaining.
Just a User Error.

(/me notes that git am and git apply are different in this regard.)

-- 
~Randy

Re: git grep failure?

[Junio C Hamano]

Randy Dunlap <rdunlap@infradead.org> writes:

> (/me notes that git am and git apply are different in this regard.)

Yup, consider that "git apply" without "--index" is a mere "make
goodness invented for Git available outside Git, as a replacement
for 'patch'", just like "git diff --no-index" is a mere "make
goodness invented for git-diff available outside Git, as a
replacement for 'diff'".  Their primary value is that they work
outside the context of Git without relying on a Git repository, but
they have limitations for not relying on a Git repository and data.

There are better alternatives (i.e., "apply" with "--index", or
"am"; "diff" without "--no-index") if you are working with Git.