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