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

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

 



[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@xxxxxxxxx> 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
>




[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]

  Powered by Linux