Hacker News new | ask | show | jobs
by gknoy 4319 days ago

  Is this a matter of insufficient knowledge of my IDE?
After writing this, I realized that it a symptom of exactly that: I'm not fully savvy with PyCharm/IntelliJ, my Python IDE of choice. I'll run down the ways I know of to access blame history (in case others don't know it exists).

1) Git -> Annotate: This is almost exactly what I wanted!

This gives a `git blame`-like column next to each code line, and clicking an item will show a summary of the commit, including both the commit message and fields modified. I can right click one of the annotations and select "show diff", and can even see the modifications to any of the files in the commit if necessary.

Unfortunately, this depends on a commit message explaining why that change mattered, AND on it being the most recent changes to those lines. Moreover, it doesn't show the full history of changes for those lines, such as if Alice added the real change, and Bob just did some whitespace changes.

I can find such information (with effort) using `gitk` or other git log browsing tools. If the most recent change (shown with git-blame) doesn't have what I need, I basically need to look at all of the changes for this file, going back from that commit, and see if I can find the one with a message that explains why ${hackity-hack} is necessary.

2) Right click a file tab or in the editor, and select Git -> Show History

This is a faster way of browsing the commit messages, but doesn't give enough information for me to tell whether that change was the one that affected the lines I care about. If it showed the diff of what the commit changed in my file, it would be more informative. (This is what gitk shows, for example.)

As far as I can tell, neither of these options is as comprehensively informative as using `gitk myfile` and backtracking from the commit that `git-blame` (or PyCharm's Git->Annotate feature) lists as the most recent change to those lines.

If comments don't describe what Is Happening or What Should Happen, they should be changed. This is much harder than maintaining unit test coverage, but I think the information is still very valuable to have in code comments rather than solely in commit messages. (It is certainly valuable to have them in commit messages as well, of course, as that documents how you felt at the time.)