5 ms·
> almost nobody ever goes looking for them there I've seen this claim a number of times and it's always so odd to me. One of my most common activities each day
by sanderjd 6y ago
> almost nobody ever goes looking for them there
I've seen this claim a number of times and it's always so odd to me. One of my most common activities each day - certainly more common than the activity of writing new code - is reading the commit history for different files. It's always surprising to me to hear that this is an uncommon thing to do.
Edit to add: But I also think comments and documentation of all kinds are good. I don't advocate good commit messages instead of comments, but rather in addition to comments. The more documentation the better.
- Braxton_Hicks 6y agoAgreed. I think the "nobody ever goes looking for them" case is common for code bases where people are not writing good useful commit messages.
- phendrenad2 6y agoCommit messages are much harder to get to for a given line of code than a comment would be.
- shepherdjerred 6y agoNot if you use a nice IDE: https://www.jetbrains.com/help/idea/investigate-changes.html#annotate https://www.jetbrains.com/help/idea/investigate-changes.html...
- rpdillon 6y agoOr even just Emacs. http://www.gnu.org/software/emacs/manual/html_node/emacs/Old-Revisions.html http://www.gnu.org/software/emacs/manual/html_node/emacs/Old...
- sanderjd 6y agoI actually find file and directory level history useful more often than the line-level annotate/blame history that seems to get all the attention. I do find line level history useful as well, I'm just saying less often. At the directory level, I look at the history of commit messages to get a sense for how the module(s) under that directory have evolved over time. At the file level, I look at the history of commit messages and often dig into the associated diff in order to see how the API and/or implementation have evolved. I'll often follow the file-level diff to the full commit to see what the entire change entailed. This gives me tons of context on the what and the why of a codebase's evolution, and it's all aided by good commit messages. Line level blame/annotate is sometimes useful when I'm trying to trace how some particular implementation came to be, but it is easy to lose the thread across deletions and renames, which I find file and directory level history to be much more resilient to.
- aflag 6y agoWhich tool do you use to view commit messages and revisions for each file? I think one of the reasons this is uncommon is due to lack of tooling (or wide-spread knowledge of them). I'd really like to be able to easily see all the previous commits that affected a specific line while I'm editing code. But I usually have to resort to interacting with git, rather than having something popping up on my screen (I use pycharm and vim regularly).
- kevinschumacher 6y agoNot the person you were replying to, but in PyCharm: - right click on the line number, click Annotate; this gives you the commit date and author in the gutter - hover over the date/author name; this gives you the commit hash and message - click on the hash itself in the popover; this shows the git commit graph on the Version Control tab - right click on the date/author name, click Annotate Revision; this opens up the version committed then, with its git blame in the gutter.
- aflag 6y agoThat's nice, and setting the options to detect movements really improves it. It'd be nice to see the commit message, rather than the author, without the need to hovering, though.
- nfRfqX5n 6y agoI use gitlens for vscode
- nemetroid 6y agoI use tig, which is a terminal UI. The "blame" view has a shortcut to jump to the commit before the one that changed a given line. This makes it easy to quickly dig backwards through the history of a file.
- recursive 6y agoVisual Studio has this. It's called "Annotate".