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?
Christopher TiwaldRe: git rev-list -S ?
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
Junio C HamanoRe: git rev-list -S ?
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.
Jeff KingRe: git rev-list -S ?
On Tue, Mar 20, 2012 at 01:53:14PM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> | $ 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
Thomas RastRe: git rev-list -S ?
Jeff King <peff@peff.net> writes:
Show 21 quoted lines
> 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