Thread (9 messages) 9 messages, 4 authors, 2019-08-03

Re: Weird behavior with git grep --recurse-submodules

From: Johannes Schindelin <hidden>
Date: 2019-07-10 11:14:41

[cC:ing Brandon via his current email address, as per .mailmap]


On Wed, 10 Jul 2019, Matheus Tavares Bernardino wrote:
On Mon, Jul 8, 2019 at 5:22 AM Daniel Zaoui [off-list ref] wrote:
quoted
Hi guys,
Hi, Daniel
quoted
I work with submodules and use git grep a lot.

I noted that when it is invoked used with --recurse-submodules, the result is not as expected for the submodules. I get submodules results as if no files were modified (like --cached option) although I would expect results taking into account the modifications.

Expected behavior:
git grep --recurse-submodules string:
- git grep string // search into main repo
- for each submodule, git grep string // search into submodule

Actual behavior:
git grep --recurse-submodules string:
- git grep string // search into main repo
- for each submodule, git grep --cached string // search into submodule

Do you get the same behavior? Am I doing something wrong? Was I understandable :-)? Is it a bug?
It seems git-grep was taking into account the worktree modifications
in submodules before f9ee2fc ("grep: recurse in-process using 'struct
repository'", 02-08-2017). I'm not sure, thought, if this behavior
change was a bug during the conversion or a project decision.

CC-ing Brandon, in case he has other inputs
quoted
git --version: git version 2.22.0
uname -a: Linux daniel 5.1.15-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 25 04:49:39 UTC 2019 x86_64 GNU/Linux

Thanks
Daniel
Best,
Matheus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help