All of lore.kernel.org
 help / color / mirror / Atom feed
* git grep broken in Fedora 21 update?
@ 2015-09-04  0:04 Rustad, Mark D
  2015-09-04  4:55 ` Jacob Keller
  2015-09-04 14:03 ` Jeff King
  0 siblings, 2 replies; 5+ messages in thread
From: Rustad, Mark D @ 2015-09-04  0:04 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

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

* Re: git grep broken in Fedora 21 update?
  2015-09-04  0:04 git grep broken in Fedora 21 update? Rustad, Mark D
@ 2015-09-04  4:55 ` Jacob Keller
  2015-09-04 13:34   ` Michael J Gruber
  2015-09-04 14:03 ` Jeff King
  1 sibling, 1 reply; 5+ messages in thread
From: Jacob Keller @ 2015-09-04  4:55 UTC (permalink / raw)
  To: Rustad, Mark D; +Cc: git

On Thu, Sep 3, 2015 at 5:04 PM, Rustad, Mark D <mark.d.rustad@intel.com> 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

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

* Re: git grep broken in Fedora 21 update?
  2015-09-04  4:55 ` Jacob Keller
@ 2015-09-04 13:34   ` Michael J Gruber
  0 siblings, 0 replies; 5+ messages in thread
From: Michael J Gruber @ 2015-09-04 13:34 UTC (permalink / raw)
  To: Jacob Keller, Rustad, Mark D; +Cc: git

Jacob Keller venit, vidit, dixit 04.09.2015 06:55:
> On Thu, Sep 3, 2015 at 5:04 PM, Rustad, Mark D <mark.d.rustad@intel.com> 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
> 

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

Also, -14 in testing contains a few fixes.

Michael

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

* Re: git grep broken in Fedora 21 update?
  2015-09-04  0:04 git grep broken in Fedora 21 update? Rustad, Mark D
  2015-09-04  4:55 ` Jacob Keller
@ 2015-09-04 14:03 ` Jeff King
  2015-09-04 16:18   ` Rustad, Mark D
  1 sibling, 1 reply; 5+ messages in thread
From: Jeff King @ 2015-09-04 14:03 UTC (permalink / raw)
  To: Rustad, Mark D; +Cc: git

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

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

* Re: git grep broken in Fedora 21 update?
  2015-09-04 14:03 ` Jeff King
@ 2015-09-04 16:18   ` Rustad, Mark D
  0 siblings, 0 replies; 5+ messages in thread
From: Rustad, Mark D @ 2015-09-04 16:18 UTC (permalink / raw)
  To: Jeff King; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

> On Sep 4, 2015, at 7:03 AM, Jeff King <peff@peff.net> 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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

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

end of thread, other threads:[~2015-09-04 16:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-04  0:04 git grep broken in Fedora 21 update? Rustad, Mark D
2015-09-04  4:55 ` Jacob Keller
2015-09-04 13:34   ` Michael J Gruber
2015-09-04 14:03 ` Jeff King
2015-09-04 16:18   ` Rustad, Mark D

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.