Martin Langhoff wrote: > And to be honest, log -G is so much more useful that I don't care a > s***t for log -S. Fair enough. :) [...] > In other words: You find a suspicious-looking line of code and you ask > "how did this horrid code come to be?", and the more horrendous the > code is, the more likely it is to be the accretion of a several > commits. In that case, which to me is the common case, log -S ain't > your friend at all. My experience is the opposite. I wonder "What did the author of this nonsense comment mean?" or "What is the purpose of this strange condition in this if () statement?". Then "git log -S" finds the culprit without showing extraneous unrelated changes (such as reindenting). It is like "git blame", but for arbitrary chunks of code instead of single lines. Then, just like with "git blame", at times the next step is to blame the parent and repeat the process using the earlier form of the code in question. It is especially handy for confusing code that spans multiple lines. (Unfortunately that is not as easy to try in gitk.) As I mentioned before, log -G and log -S are fairly dissimilar operations. Thanks, Jonathan -- 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