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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html