git rev-list -S ?

git rev-list -S ?

[Holger Hellmuth]

I read the GsoC page about the ultimate tracking tool just now and 
couldn't find the -S option in git rev-list documentation nor in 'What's 
cooking'. Stealth command or am I just blind?

Re: git rev-list -S ?

[Christopher Tiwald]

On Tue, Mar 20, 2012 at 07:34:12PM +0100, Holger Hellmuth wrote:
> I read the GsoC page about the ultimate tracking tool just now and
> couldn't find the -S option in git rev-list documentation nor in
> 'What's cooking'. Stealth command or am I just blind?

I use 'git log -S<string>' to pickaxe search my histories for commits
that affect <string> nigh daily. I can't find reference to it in
'git rev-list', but I know similar functionality is available in
'git diff'. Maybe it's just a typo in the wiki page?

--
Christopher Tiwald

Re: git rev-list -S ?

[Junio C Hamano]

Holger Hellmuth <hellmuth@ira.uka.de> writes:

> I read the GsoC page about the ultimate tracking tool just now and
> couldn't find the -S option in git rev-list documentation...

Slippery finger.

|    $ git log -S'it drives an external
|   an external' master Documentation/RelNotes

is a way to find commits that introduced and then removed the block of
text to files in the named directory, starting at the tip of 'master'.

Most of the "ultimate tracking tool" dream has already been realized in
"git blame" except one major part.  Once you find where the blame lies,
the tool _could_ help the user to find where these blamed lines came from
more than it currently does.  Were they typed anew?  Were similar lines
removed by the commit from other files?  Often people run "blame" on a
line range they are interested in, find the commits that were blamed, look
at "git show $the_found_commit" to see if they can find similar lines in
deleted parts of other files and then finally run blame again on the
deleted line range of these other files starting from the parent commit of
the found commit to do this (and this needs to be repeated).  A good GUI
should be able to help this process quite a lot, if backed by a good logic
to detect "similar" code blocks.

Re: git rev-list -S ?

[Jeff King]

On Tue, Mar 20, 2012 at 01:53:14PM -0700, Junio C Hamano wrote:

> |    $ git log -S'it drives an external
> |   an external' master Documentation/RelNotes
> 
> is a way to find commits that introduced and then removed the block of
> text to files in the named directory, starting at the tip of 'master'.
> 
> Most of the "ultimate tracking tool" dream has already been realized in
> "git blame" except one major part.  Once you find where the blame lies,
> the tool _could_ help the user to find where these blamed lines came from
> more than it currently does.  Were they typed anew?  Were similar lines
> removed by the commit from other files?  Often people run "blame" on a
> line range they are interested in, find the commits that were blamed, look
> at "git show $the_found_commit" to see if they can find similar lines in
> deleted parts of other files and then finally run blame again on the
> deleted line range of these other files starting from the parent commit of
> the found commit to do this (and this needs to be repeated).  A good GUI
> should be able to help this process quite a lot, if backed by a good logic
> to detect "similar" code blocks.

Related to this is the line-level history browser project. The idea was
basically to get a log-like view (i.e., reverse chronological commits)
of a chunk of code, tracing the ancestry of a particular chunk of lines.

This was done by Bo Yang as a GSoC project in 2010, but the code still
hasn't been merged. As I recall, it mostly works, but there are perhaps
some corner cases or ugly parts of the code still to be re-worked.
Thomas Rast was cleaning it up some, and could say more on the current
state.

-Peff

Re: git rev-list -S ?

[Thomas Rast]

Jeff King <peff@peff.net> writes:

> On Tue, Mar 20, 2012 at 01:53:14PM -0700, Junio C Hamano wrote:
>
>> |    $ git log -S'it drives an external
>> |   an external' master Documentation/RelNotes
>> 
>> is a way to find commits that introduced and then removed the block of
>> text to files in the named directory, starting at the tip of 'master'.
>> 
>> Most of the "ultimate tracking tool" dream has already been realized in
>> "git blame" except one major part.  Once you find where the blame lies,
>> the tool _could_ help the user to find where these blamed lines came from
>> more than it currently does.
> 
> Related to this is the line-level history browser project. The idea was
> basically to get a log-like view (i.e., reverse chronological commits)
> of a chunk of code, tracing the ancestry of a particular chunk of lines.
>
> This was done by Bo Yang as a GSoC project in 2010, but the code still
> hasn't been merged. As I recall, it mostly works, but there are perhaps
> some corner cases or ugly parts of the code still to be re-worked.
> Thomas Rast was cleaning it up some, and could say more on the current

This is all correct.  It mostly works, which is the main impediment to
further work :-)  You can try it by merging

  git://github.com/trast/git.git line-log-cleanup

It segfaults if you attempt to track more than one range, however.

I have started some rewriting, which tries to phrase it more in terms of
simple operations on sets of lines, and pushed that as

  git://github.com/trast/git.git line-log-WIP

This was successful in that the newly written code is easier to read and
completely broken.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch