An idealistic reason for encouraging longer-form commit messages is that they have the side effect of more coherent commits, making the history easier to navigate, making the history more useful, and so your workflow will probably use the history more.

A practical reason for longer-form commit messages even in modern PR workflows is that they allow you to create and view commentary on a group of changes across files without leaving your editor.

As an interface to git, nothing beats magit. Even if you never use Emacs for editing any text files, it's useful as a magit runner.

VSCode git-lens. Mandatory extension. Either way, I think both are useful, although for documenting weird code I think code comments are more important. I the commit message you should explain why you change the code. In the code, why it works like that.

gitlens is incredible. It passively educates on the git history so you learn about how old each section is and who was mostly behind it or worked with it last without ever requiring dedicated effort since it just sits there at the end of the selected line.

I still wouldn't use git as a replacement for comments since git history is wiped out all the time. Moving files or reformatting or a million other things could remove a critical commit message.

It’s super useful, rarely, when things haven’t moved around or someone wrote a good commit msg.

It’s a dumb idea, because that content gets lost as soon as you move things around.

Counter-point: moving things around in a way which doesn't preserve history is a dumb idea.

Moving/renaming a file? Commit the deletion and insertion together, preferably with no other changes (including to the contents of the file; commit those afterwards). In the best case, VC will treat this as a move and showing the history will include that of the old place/name. In the worst case, that history of file 'foo' will "end" with a commit like 'Rename bar to foo', with a diff showing the content moving from 'bar' to 'foo'; we can continue reading the history by switching to 'bar' if we want.

Moving code from one file to another? Similar story: commit the insertion and removal together; preferably with little/nothing else in that commit; preferably with a commit message explaining the change. This way, the code doesn't appear from nowhere in the commit history: when we look at the commit where it appears, we will also see where it came from before.

Moving a file from one repo to another? Dump that file's history as a patch, apply that patch in the new repo, then clean up (e.g. rename, move, etc. as appropriate). Alternatively, for larger sets of changes, add the old repo as a remote for the new repo, make a branch in the old repo which contains only those parts we want to move, fetch that branch into the new repo and merge it, then remove the remote.

> moving things around in a way which doesn't preserve history is a dumb idea

I don’t disagree with you but you can’t prevent it.

If you use an IntelliJ based IDE you can view commit entries for each line in the gutter.

I prefer comments but yes. If something doesn't make sense, one of my first things to try is to check the `git blame` and see if there's anything recent (or close to when the bug reportedly appeared, such as between two versions). Sometimes the commit message tells me something but usually not, but just looking up the ticket number from the commit message on our issue tracker can be enough hint sometimes. Especially on our SaaS product, if a problem just popped up in Prod and especially if the bug seems both easy to reproduce and feels like "wasn't us" I'll make a quick guess on a 'known good version', try to reproduce and the `git bisect` to find the culprit. Not to blame but just to figure out what's wrong in a very easy way. Sometimes I can fix it easily from that or ping the person who made the boo boo and they will usually know how to fix it quickly.

In the context of regular development? I almost never do any of that.

Not with every file but I have a question as to why something might exist or why it's implemented the way it is or it just doesn't look quite right then I'd absolutely go back and read the commit message that goes with the code - "Blame" feature works well here, I use TortoiseSVN.

The GitHub web interface, specifically the "blame" view for a file.

That only shows the most recent commit, which is IME often not substantive, just some treewide commit like "autoformat" or "moved class into another file" or whatever. I can click on the parent commit button repeatedly until I find all the info but that's really not a good interface for exposing the history of a class.

Each line in the GitHub web blame interface has a little icon which, when you hover over it, says "View blame prior to this change" - I use that all the time.

Yeah that's the parent button I was referring to in my comment.

I use fugitive, which lets me pop open a blame view for code I'm looking at and trace its lineage. It's often helpful, and when the commit messages are good, very helpful.