# git grep failure?

7 messages from 2026-03-18 to 2026-03-19. Participants: Randy Dunlap, Jeff King, Junio C Hamano.
Thread: https://gitlist.dev/t/65298

## Randy Dunlap, 2026-03-18 23:28

Subject: git grep failure?
Message-ID: <7bbcda60-dad4-41d4-b994-c19f83f37e2f@infradead.org>
URL: https://gitlist.dev/e/7bbcda60-dad4-41d4-b994-c19f83f37e2f%40infradead.org

```
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


```

## Jeff King, 2026-03-19 00:38

Subject: Re: git grep failure?
Message-ID: <20260319003829.GA3530301@coredump.intra.peff.net>
URL: https://gitlist.dev/e/20260319003829.GA3530301%40coredump.intra.peff.net
In-Reply-To: <7bbcda60-dad4-41d4-b994-c19f83f37e2f@infradead.org>

```
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

```

## Randy Dunlap, 2026-03-19 04:42

Subject: Re: git grep failure?
Message-ID: <2c943182-d5d7-4f72-ab97-8d07bf4ed216@infradead.org>
URL: https://gitlist.dev/e/2c943182-d5d7-4f72-ab97-8d07bf4ed216%40infradead.org
In-Reply-To: <20260319003829.GA3530301@coredump.intra.peff.net>

```


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


```

## Junio C Hamano, 2026-03-19 05:16

Subject: Re: git grep failure?
Message-ID: <xmqq7br8o0uf.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqq7br8o0uf.fsf%40gitster.g
In-Reply-To: <2c943182-d5d7-4f72-ab97-8d07bf4ed216@infradead.org>

```
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.

```

## Jeff King, 2026-03-19 15:53

Subject: Re: git grep failure?
Message-ID: <20260319155326.GA3611913@coredump.intra.peff.net>
URL: https://gitlist.dev/e/20260319155326.GA3611913%40coredump.intra.peff.net
In-Reply-To: <2c943182-d5d7-4f72-ab97-8d07bf4ed216@infradead.org>

```
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

```

## Randy Dunlap, 2026-03-19 16:47

Subject: Re: git grep failure?
Message-ID: <7e8159fb-f7ff-41f0-8955-5ed2dd5dc7fe@infradead.org>
URL: https://gitlist.dev/e/7e8159fb-f7ff-41f0-8955-5ed2dd5dc7fe%40infradead.org
In-Reply-To: <20260319155326.GA3611913@coredump.intra.peff.net>

```


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


```

## Junio C Hamano, 2026-03-19 17:24

Subject: Re: git grep failure?
Message-ID: <xmqqtsublolr.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqtsublolr.fsf%40gitster.g
In-Reply-To: <7e8159fb-f7ff-41f0-8955-5ed2dd5dc7fe@infradead.org>

```
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.

```
