Most recent revision that contains a string

Most recent revision that contains a string

[Nikolaus Rath]

Hello,

What's the easiest way to find the most recent revision (of any file in
the repository, including those that have been deleted in the current
HEAD) that contains a given string?

I was hoping that "git grep" would do this (like in Mercurial), but as
far as I can tell it only greps through the working copy. Or is there a
trick that I'm missing?

Thanks,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: Most recent revision that contains a string

[Josh Triplett]

On Sat, Aug 20, 2016 at 02:41:35PM -0700, Nikolaus Rath wrote:
> Hello,
> 
> What's the easiest way to find the most recent revision (of any file in
> the repository, including those that have been deleted in the current
> HEAD) that contains a given string?
> 
> I was hoping that "git grep" would do this (like in Mercurial), but as
> far as I can tell it only greps through the working copy. Or is there a
> trick that I'm missing?

git grep can search through any arbitrary blob, tree, commit, or tag.
So you can search through HEAD~10, or HEAD~10:path/to/directory, or
HEAD~10:path/to/file.  (You can also search the index with --cached, and
various other options exist as well.)

If you want to find a change that introduces or removes a particular
string, you could use "git log -S".  That doesn't allow regexes, but it
might do what you want.  "git grep" will find occurrences of the string
in the current version, and if it has been removed, "git log -S" will
find the removal.

I don't know of any way to do that in one file-oriented step, searching
backward through the first occurrence of every path, including deleted
paths.

Re: Most recent revision that contains a string

[Andreas Schwab]

On Aug 20 2016, Josh Triplett <josh@joshtriplett.org> wrote:

> If you want to find a change that introduces or removes a particular
> string, you could use "git log -S".  That doesn't allow regexes,

It does, actually, see --pickaxe-regex.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Most recent revision that contains a string

[Josh Triplett]

On Sun, Aug 21, 2016 at 10:13:33AM +0200, Andreas Schwab wrote:
> On Aug 20 2016, Josh Triplett <josh@joshtriplett.org> wrote:
> > If you want to find a change that introduces or removes a particular
> > string, you could use "git log -S".  That doesn't allow regexes,
> 
> It does, actually, see --pickaxe-regex.

Thanks; I found that after looking up "git log -G", which Eric Wong
mentioned in another reply.

Re: Most recent revision that contains a string

[Eric Wong]

Nikolaus Rath <Nikolaus@rath.org> wrote:
> What's the easiest way to find the most recent revision (of any file in
> the repository, including those that have been deleted in the current
> HEAD) that contains a given string?

I normally do something like:

	git log -r --raw -p -SSTRING
	git log -r --raw -p -GREGEXP

You can also add --diff-filter=D to filter only on deletes.


Btw, please don't set these headers on kernel.org lists:

	Mail-Copies-To: never
	Mail-Followup-To: git@vger.kernel.org

Like any mail server, vger fails from time-to-time and
reply-to-all prevents it from being a single point of failure.
Thanks.

Re: Most recent revision that contains a string

[Nikolaus Rath]

On Aug 21 2016, Eric Wong <e@80x24.org> wrote:
> Nikolaus Rath <Nikolaus@rath.org> wrote:
>> What's the easiest way to find the most recent revision (of any file in
>> the repository, including those that have been deleted in the current
>> HEAD) that contains a given string?
>
> I normally do something like:
>
> 	git log -r --raw -p -SSTRING
> 	git log -r --raw -p -GREGEXP
>
> You can also add --diff-filter=D to filter only on deletes.

Great, thanks!

> Btw, please don't set these headers on kernel.org lists:
>
> 	Mail-Copies-To: never
> 	Mail-Followup-To: git@vger.kernel.org
>
> Like any mail server, vger fails from time-to-time and
> reply-to-all prevents it from being a single point of failure.

Huh? If the list-server fails only I will receive the message so it's
still lost for everyone else. But I am more than happy to take this
little risk if it saves me from the nuisance of getting duplicate
responses.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: Most recent revision that contains a string

[Junio C Hamano]

Nikolaus Rath <Nikolaus@rath.org> writes:

>> Btw, please don't set these headers on kernel.org lists:
>>
>> 	Mail-Copies-To: never
>> 	Mail-Followup-To: git@vger.kernel.org
>>
>> Like any mail server, vger fails from time-to-time and
>> reply-to-all prevents it from being a single point of failure.
>
> Huh? If the list-server fails only I will receive the message so it's
> still lost for everyone else. But I am more than happy to take this
> little risk if it saves me from the nuisance of getting duplicate
> responses.

On a mailing list, your readers' time is more valuable than yours,
simply because there are a lot more of them.

I am typing this message ONLY because I want to talk to YOU, and I
want your address to be on its To: field, with Eric and the list on
Cc: field.  The recipients can prioritize their incoming messages by
reading what's addressed directly to them first and when they have
leftover time they can read ones that they are CC'ed, but because
you used Mail-Followup-To: I had to correct the headers manually,
which means you stole time from me.  And if I didn't then your
Mail-Followup-to: would have stolen time from the other recipients.

Please don't use it on this list.