Konstantin Khomoutov <kostix+git@xxxxxxxxx> writes: > Still, I welcome you to read the sort-of "reference" post by Linus > Torvalds [1] in which he explains the reasoning behind this approach > implemented in Git. IMO, understanding the reasoning behind the idea > is much better than just mechanically learning how to use it. > > The whole thread (esp. Torvalds' replies) is worth reading, but that > particular mail summarizes the whole thing very well. > > (The reference link to it used to be [2], but Gmane is not fully > recovered to be able to display it.) > > 1. http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@xxxxxxxxxxxxxxx/ > 2. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217 Indeed. Thanks for providing a link to it here ;-) The message is the most important one in the early history of Git, and it still is one of the most important messages in the Git mailing-list archive. "git log -S<block>" was designed to take a block of text (even though people misuse it and feed a single line to it) exactly because it wanted to serve the "tracking when that file+line changed" part in that vision. The rename detection in "diff" was meant to be used on the commit "git log -S<block>" finds to see if the found change came from another file so that the user can decide that "digging further" part needs to be done for another file. "git blame" with -M and -C options were done to mostly automate the "drilling down" process that finds the last commit that touched each line in the above process, and when used with tools like "tig", you can even peel one commit back and "zoom down" if the found commit is an uninteresting one (e.g. a change with only code formatting). One thing that is still missing in the current version of Git, compared to the "ideal SCM" the message envisioned, is the part that notices: "oops, that line didn't even exist in the previous version, BUT I FOUND FIVE PLACES that matched almost perfectly in the same diff, and here they are".