threads / discuss / 15162

teach git diff -v/--invert-match?

Subject: teach git diff -v/--invert-match?

## tl;dr

7 messages between Aug 22, 2008 and Aug 27, 2008.

replies: 6people: 4as markdown or json

Brian Ericson· Aug 22, 2008, 14:51 UTC · lore

I'm wondering what it would take to teach git diff to invert the -S string (like git grep).

I'm finding git diff -S<string> [--pickaxe-regex] to be really useful, but find I have cases where I want to ignore differences. For example, I might not care if the only changes to a Java file, for example, are related to import statements. I'd like to be able to do something like "git diff -S'^import' --pickaxe-regex -v". I'll admit I can get by with something like "git diff -S'^[^i]' --pickaxe-regex", but am pining for -v/--invert-match.

Jeff King· Aug 22, 2008, 19:39 UTC · re: Brian Ericson · lore

Re: teach git diff -v/--invert-match?

On Fri, Aug 22, 2008 at 09:51:16AM -0500, Brian Ericson wrote:
> I'm wondering what it would take to teach git diff to invert the -S  
> string (like git grep).
I think you would have to figure out the desired semantics first.
Show 7 quoted lines
> I'm finding git diff -S<string> [--pickaxe-regex] to be really useful,  
> but find I have cases where I want to ignore differences.  For example, I 
> might not care if the only changes to a Java file, for example, are  
> related to import statements.  I'd like to be able to do something like  
> "git diff -S'^import' --pickaxe-regex -v".  I'll admit I can get by with  
> something like "git diff -S'^[^i]' --pickaxe-regex", but am pining for  
> -v/--invert-match.

I would have thought "-v" meant "match any changes which do not have this pattern". But you want "match any changes that have any line which does not have this pattern."

IOW, mine would not match any changes which used an import statement, whereas yours would not match any changes which are _only_ import statements.

-Peff
Brian Ericson· Aug 22, 2008, 21:29 UTC · re: Jeff King · lore

Re: teach git diff -v/--invert-match?

I was just working on a reply to my own email as I realized it was only dumb-luck that converted 1200 noisy changes into a couple of dozen. "-S" matches only the string itself, not the line the string resides on. So, -Sxyz will match if "xyz" itself was added or deleted in the diff (if "xyz" is on a line that's changed but did not itself change, it won't match). Funny that I actually knew this -- I use it to look for System.out.println additions among other things.

Interestingly, if I wanted to know if an import changed (on top of knowing if imports were added or deleted), eg: -import foo; +import bar;

I couldn't tell you how to do it. The string "import" didn't change. I'd've guessed that "-S'import.*;' --pickaxe-regex" would have been sufficient, but that doesn't work.

Jeff King wrote:
Show 9 quoted lines
> On Fri, Aug 22, 2008 at 09:51:16AM -0500, Brian Ericson wrote:
>
>   
>> I'm wondering what it would take to teach git diff to invert the -S  
>> string (like git grep).
>>     
>
> I think you would have to figure out the desired semantics first.
>   

I think mostly what I want is a happy marriage between git diff & git grep so that if the changed lines matched (or didn't match) the file would show up (or not). I'd like to grep added and removed lines (the diff itself) for a pattern and either include or exclude the file based on matches.

Show 14 quoted lines
>   
>> I'm finding git diff -S<string> [--pickaxe-regex] to be really useful,  
>> but find I have cases where I want to ignore differences.  For example, I 
>> might not care if the only changes to a Java file, for example, are  
>> related to import statements.  I'd like to be able to do something like  
>> "git diff -S'^import' --pickaxe-regex -v".  I'll admit I can get by with  
>> something like "git diff -S'^[^i]' --pickaxe-regex", but am pining for  
>> -v/--invert-match.
>>     
>
> I would have thought "-v" meant "match any changes which do not have
> this pattern". But you want "match any changes that have any line which
> does not have this pattern."
>   

Right. Good summary! It's probably not accurate to use "-S" for my interpretation unless --pickaxe-regex behaved more as I outlined above. It's probably a subtle enough difference

> IOW, mine would not match any changes which used an import statement,
> whereas yours would not match any changes which are _only_ import
> statements.
>   

The current behavior seems to work well to answer questions like "has somebody added a System.out.println", I'd like it to be able to ignore or consider files based on line changes that contain a string where the string itself did not change.

Show 8 quoted lines
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>   
Jeff King· Aug 22, 2008, 21:42 UTC · re: Brian Ericson · lore

Re: teach git diff -v/--invert-match?

On Fri, Aug 22, 2008 at 04:29:31PM -0500, Brian Ericson wrote:
Show 7 quoted lines
> I was just working on a reply to my own email as I realized it was
> only  dumb-luck that converted 1200 noisy changes into a couple of
> dozen.  "-S" matches only  the string itself, not the line the string
> resides on.  So, -Sxyz will match if  "xyz" itself was added or
> deleted in the diff (if "xyz" is on a line that's changed but  did not
> itself change, it won't match).  Funny that I actually knew this -- I
> use it to look for System.out.println additions among other things.

Yes (though I couldn't have told you that without experimenting -- I always assumed it checked whole lines).

> Interestingly, if I wanted to know if an import changed (on top of
> knowing if imports were added or deleted), eg: -import foo; +import
> bar;

That is a bit harder, and AFAIK not possible with -S. You could always post process the log output. E.g.,:

  git log -p | perl -ne '
    BEGIN { $/ = "commit " }
    chomp; print if /^\+import /
  '
which lets you get quite fancy with the matching.
> The current behavior seems to work well to answer questions like "has
> somebody added a System.out.println",

The usual question (for me, anyway) is "when did X get introduced?" when looking for a token.

-Peff
Junio C Hamano· Aug 22, 2008, 21:44 UTC · re: Jeff King · lore

Re: teach git diff -v/--invert-match?

Jeff King <peff@peff.net> writes:
Show 12 quoted lines
> On Fri, Aug 22, 2008 at 04:29:31PM -0500, Brian Ericson wrote:
>
>> I was just working on a reply to my own email as I realized it was
>> only  dumb-luck that converted 1200 noisy changes into a couple of
>> dozen.  "-S" matches only  the string itself, not the line the string
>> resides on.  So, -Sxyz will match if  "xyz" itself was added or
>> deleted in the diff (if "xyz" is on a line that's changed but  did not
>> itself change, it won't match).  Funny that I actually knew this -- I
>> use it to look for System.out.println additions among other things.
>
> Yes (though I couldn't have told you that without experimenting -- I
> always assumed it checked whole lines).

The -Sstring counts the number of 'string' in preimage and postimage and skips the commit if they are the same. Nothing more.

Paolo Bonzini· Aug 25, 2008, 09:41 UTC · re: Jeff King · lore

Re: teach git diff -v/--invert-match?

> I would have thought "-v" meant "match any changes which do not have
> this pattern". But you want "match any changes that have any line which
> does not have this pattern."

Yours could be "-L/--without-match" (in grep, -L/--files-without-match only prints the names of files containing no match).

Paolo
Jeff King· Aug 27, 2008, 00:38 UTC · re: Paolo Bonzini · lore

Re: teach git diff -v/--invert-match?

On Mon, Aug 25, 2008 at 11:41:37AM +0200, Paolo Bonzini wrote:
Show 6 quoted lines
> > I would have thought "-v" meant "match any changes which do not have
> > this pattern". But you want "match any changes that have any line which
> > does not have this pattern."
> 
> Yours could be "-L/--without-match" (in grep, -L/--files-without-match
> only prints the names of files containing no match).

Ah, yes, that would be better. I think we decided that Brian's original problem didn't really work with -S, and I don't actually need this behavior enough to implement it. But your suggestion is a good one if somebody cares to do so.

-Peff

← back to recent threads