git grep broken in Fedora 21 update?

I just found a case where grep and git grep yield different results. Inside the ixgbe directory of the Linux kernel I did:

$ grep enter_lplu *.[ch]

And got the following:

ixgbe_main.c:	if (adapter->hw.phy.ops.enter_lplu) {
ixgbe_main.c:		adapter->hw.phy.ops.enter_lplu(&adapter->hw);
ixgbe_type.h:	s32 (*enter_lplu)(struct ixgbe_hw *);
ixgbe_x550.c:/** ixgbe_enter_lplu_x550em - Transition to low power states
ixgbe_x550.c:static s32 ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)
ixgbe_x550.c:			phy->ops.enter_lplu = ixgbe_enter_lplu_t_x550em;

But when I did:

$ git grep enter_lplu

I got:

ixgbe_main.c:   if (adapter->hw.phy.ops.enter_lplu) {
ixgbe_main.c:           adapter->hw.phy.ops.enter_lplu(&adapter->hw);
ixgbe_type.h:   s32 (*enter_lplu)(struct ixgbe_hw *);
ixgbe_x550.c:/** ixgbe_enter_lplu_x550em - Transition to low power states
ixgbe_x550.c:static s32 ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)

You can see that git grep missed the line in ixgbe_x550.c that had two hits on the string.

This was with git 2.1.0 in Fedora 21. I use git grep a lot and never noticed a problem before. I just updated my Fedora 21 system yesterday, so I have to figure that has something to do with it. I checked and git didn't get updated, so I figure it must be a library that is really broken.

I see in my update log that pcre was updated to:

pcre.x86_64 0:8.35-12.fc21
pcre-devel.x86_64 0:8.35-12.fc21

Yet the grep command is unaffected.

--
Mark Rustad, Networking Division, Intel Corporation

On Thu, Sep 3, 2015 at 5:04 PM, Rustad, Mark D [off-list ref] wrote:

I just found a case where grep and git grep yield different results. Inside the ixgbe directory of the Linux kernel I did:

$ grep enter_lplu *.[ch]

And got the following:

ixgbe_main.c:   if (adapter->hw.phy.ops.enter_lplu) {
ixgbe_main.c:           adapter->hw.phy.ops.enter_lplu(&adapter->hw);
ixgbe_type.h:   s32 (*enter_lplu)(struct ixgbe_hw *);
ixgbe_x550.c:/** ixgbe_enter_lplu_x550em - Transition to low power states
ixgbe_x550.c:static s32 ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)
ixgbe_x550.c:                   phy->ops.enter_lplu = ixgbe_enter_lplu_t_x550em;

But when I did:

$ git grep enter_lplu

I got:

ixgbe_main.c:   if (adapter->hw.phy.ops.enter_lplu) {
ixgbe_main.c:           adapter->hw.phy.ops.enter_lplu(&adapter->hw);
ixgbe_type.h:   s32 (*enter_lplu)(struct ixgbe_hw *);
ixgbe_x550.c:/** ixgbe_enter_lplu_x550em - Transition to low power states
ixgbe_x550.c:static s32 ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)

You can see that git grep missed the line in ixgbe_x550.c that had two hits on the string.

This was with git 2.1.0 in Fedora 21. I use git grep a lot and never noticed a problem before. I just updated my Fedora 21 system yesterday, so I have to figure that has something to do with it. I checked and git didn't get updated, so I figure it must be a library that is really broken.

I see in my update log that pcre was updated to:

pcre.x86_64 0:8.35-12.fc21
pcre-devel.x86_64 0:8.35-12.fc21

Yet the grep command is unaffected.

--
Mark Rustad, Networking Division, Intel Corporation

I don't know if command line grep uses pcre?

Does git-grep by default ignore changes not yet committed? That was my
first thought but I am not very familiar with the tool.

Regards,
Jake

Jacob Keller venit, vidit, dixit 04.09.2015 06:55:

On Thu, Sep 3, 2015 at 5:04 PM, Rustad, Mark D [off-list ref] wrote:

quoted

I just found a case where grep and git grep yield different results. Inside the ixgbe directory of the Linux kernel I did:

$ grep enter_lplu *.[ch]

And got the following:

ixgbe_main.c:   if (adapter->hw.phy.ops.enter_lplu) {
ixgbe_main.c:           adapter->hw.phy.ops.enter_lplu(&adapter->hw);
ixgbe_type.h:   s32 (*enter_lplu)(struct ixgbe_hw *);
ixgbe_x550.c:/** ixgbe_enter_lplu_x550em - Transition to low power states
ixgbe_x550.c:static s32 ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)
ixgbe_x550.c:                   phy->ops.enter_lplu = ixgbe_enter_lplu_t_x550em;

But when I did:

$ git grep enter_lplu

I got:

ixgbe_main.c:   if (adapter->hw.phy.ops.enter_lplu) {
ixgbe_main.c:           adapter->hw.phy.ops.enter_lplu(&adapter->hw);
ixgbe_type.h:   s32 (*enter_lplu)(struct ixgbe_hw *);
ixgbe_x550.c:/** ixgbe_enter_lplu_x550em - Transition to low power states
ixgbe_x550.c:static s32 ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)

You can see that git grep missed the line in ixgbe_x550.c that had two hits on the string.

This was with git 2.1.0 in Fedora 21. I use git grep a lot and never noticed a problem before. I just updated my Fedora 21 system yesterday, so I have to figure that has something to do with it. I checked and git didn't get updated, so I figure it must be a library that is really broken.

I see in my update log that pcre was updated to:

pcre.x86_64 0:8.35-12.fc21
pcre-devel.x86_64 0:8.35-12.fc21

Yet the grep command is unaffected.

--
Mark Rustad, Networking Division, Intel Corporation

I don't know if command line grep uses pcre?

Does git-grep by default ignore changes not yet committed? That was my
first thought but I am not very familiar with the tool.

Regards,
Jake

Can you downgrade pcre and check whether that's the reason?

Also, -14 in testing contains a few fixes.

Michael

On Fri, Sep 04, 2015 at 12:04:38AM +0000, Rustad, Mark D wrote:

You can see that git grep missed the line in ixgbe_x550.c that had two hits on the string.

This was with git 2.1.0 in Fedora 21. I use git grep a lot and never
noticed a problem before. I just updated my Fedora 21 system
yesterday, so I have to figure that has something to do with it. I
checked and git didn't get updated, so I figure it must be a library
that is really broken.

I see in my update log that pcre was updated to:

pcre.x86_64 0:8.35-12.fc21
pcre-devel.x86_64 0:8.35-12.fc21

Yet the grep command is unaffected.

I don't think "git grep" should be using pcre unless you specified "-P"
on the command line (which might be an interesting experiment, to see if
it improves the result).

It shouldn't be affected by your working tree state. "git grep" without
arguments searches the working tree, just like grep. It might omit a
file that is not tracked, but given that the missing line is from a file
which _does_ have other results, that's clearly not the problem.

Is it possible that git _is_ producing the hit, but it is getting eaten
by the pager or something like that? Does "git --no-pager grep
enter_lplu" produce the same results?

I don't think there have been any git bugs in this area for quite a
while. In your position I'd try building from source to see if a freshly
built version has the same problem.

-Peff

On Sep 4, 2015, at 7:03 AM, Jeff King [off-list ref] wrote:

Is it possible that git _is_ producing the hit, but it is getting eaten
by the pager or something like that? Does "git --no-pager grep
enter_lplu" produce the same results?

Well what do you know. Adding --no-pager gave me the right results. I wonder if the output isn't getting flushed to the pipe or something. In any case, I can add --no-pager to the alias I normally use and I'll be happy. The root cause will just gnaw at me for a while...

Hmm. Doing git grep enter_lplu | cat - also worked.

--
Mark Rustad, Networking Division, Intel Corporation