git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* Weird behavior with git grep --recurse-submodules
@ 2019-07-08  8:14 Daniel Zaoui
  2019-07-10  6:43 ` Matheus Tavares Bernardino
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Zaoui @ 2019-07-08  8:14 UTC (permalink / raw)
  To: git

Hi guys,

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?

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Weird behavior with git grep --recurse-submodules
  2019-07-08  8:14 Weird behavior with git grep --recurse-submodules Daniel Zaoui
@ 2019-07-10  6:43 ` Matheus Tavares Bernardino
  2019-07-10 11:14   ` Johannes Schindelin
  0 siblings, 1 reply; 3+ messages in thread
From: Matheus Tavares Bernardino @ 2019-07-10  6:43 UTC (permalink / raw)
  To: Daniel Zaoui; +Cc: git, Brandon Williams

On Mon, Jul 8, 2019 at 5:22 AM Daniel Zaoui <jackdanielz@eyomi.org> wrote:
>
> Hi guys,

Hi, Daniel

> 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

> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Weird behavior with git grep --recurse-submodules
  2019-07-10  6:43 ` Matheus Tavares Bernardino
@ 2019-07-10 11:14   ` Johannes Schindelin
  0 siblings, 0 replies; 3+ messages in thread
From: Johannes Schindelin @ 2019-07-10 11:14 UTC (permalink / raw)
  To: Matheus Tavares Bernardino; +Cc: Brandon Williams, Daniel Zaoui, git

[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 <jackdanielz@eyomi.org> wrote:
> >
> > Hi guys,
>
> Hi, Daniel
>
> > 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
>
> > 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
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-08  8:14 Weird behavior with git grep --recurse-submodules Daniel Zaoui
2019-07-10  6:43 ` Matheus Tavares Bernardino
2019-07-10 11:14   ` Johannes Schindelin

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox