Do people actually read commit messages? I don't have much experience working on large projects with a larger team, but I keep repositories both for personal things and work so I can look at older versions. I have however never actually looked at my own commit messages, even though I try to keep them informative. I instead search through commits based on strings added/removed or file paths touched.
As such, multiline commit messages (whether added on the command line or via the editor) seem doubly pointless to me.
When inheriting a project, you use git blame a lot. Who wrote it, when it was written and any hints as to why it was written. If it has a task number like "fixes #1402" and you still have access to the issues, that's great.
If it is like "f*ck python" or "lol java sux" that's a good indication that it was a syntax problem or a trivial mistake.
If it is like "a" or "aaa" or "x" it's just useless and you are on your own.
> If it has a task number like "fixes #1402" and you still have access to the issues, that's great.
If. The flip side is that when you don't have the issue tracker (I'm unclear as to whether they deleted it, or it just didn't come along when the product was acquired), it's maddening. "This [massive, opaque] change fixes #123" "...gee, thanks; that tells me loads."
When the first line of the commit is just "Fixes 1429", that's annoying. It belongs on a subsequent line.
I can look through the list of commits for recent changes that seem like they might have caused a new bug, but a list of numbers is no help at all there.
> Do people actually read commit messages? I don't have much experience working on large projects with a larger team
I find them super useful even for personal, my-eyes-only code! They really help answering "why the hell did I write this line of code like that when this alternative version would be much simpler?". It usually goes "oh, there's the commit that changed it from the obvious thing to the weird thing", and then if I've been a good me, the commit message describes the rationale.
Yes, code comments can serve some of the same purpose, but they typically document why code is the way it is, not change of said code.
For the maintainability of a large project with a lot of contributors, the quality of the commit messages is more important than the quality of the code itself. The code and the comments in it only contains the how and what is happening, and even those can get really muddled up in projects where something gets changed over and over again by different people over a long time.
The commit messages provide the why. They grant you a window to the perspective of the person who did the change, explaining why they did something the way they did.
Do you know the tool "git blame"? (You can also use it with "git gui blame", from Github, or from many text editors). It tells you which commit last changed each line of code. Then you can click and see the surrounding history and context.
If the git history is "well written" this is an invaluable tool for understanding the code and how it came to be the way it is! Super useful when working on large code-bases where lots of different people collaborate.
I use git blame, but in the same way I use the rest of git: I find the commit which changed a line, and then look at what else that commit and the ones before/after it did.
I guess there is some value in being able to have a quick description of the commits shown when looking at the blame output though.
The git command-line blame is quite awkward, both in syntax and in functional limitations, in almost any situation it's a lot better to use a visual tool such as "git gui blame"
Which part is it that confuses you? On github the commit messages and hashes on the left hand side indicate the last commit that touched those lines, and you can click on them to see the full commits, including changes made to other files. Alternatively you can click on the "View blame prior to this change"-icon (between the commit messages and the code), which will do as the name suggests: Show the commit which previously changed those lines.
> As such, multiline commit messages (whether added on the command line or via the editor) seem doubly pointless to me
So your commit messages are always made of less than 80 characters, how can you claim that they are informative??
Personally I very rarely manage to keep them in a single line, almost always there's something to dump from my mind that will help a lot when I or someone else will have to deal with that commit a few months from now.
You don't read your messages because they really are not informative!
I guess "not nonsensical" would be more appropriate than "informative" :)
I tend to dump information like that in "// NB (my name, current date) tralala"-style comments. Do you have git integrated in your editor so you have git-blame-style commit messages next to your code? If that is the case, I guess putting the information in the commit messages makes sense.
Maybe it just comes down to how we choose to store auxiliary information.
> I tend to dump information like that in "// NB (my name, current date) tralala"-style comments. Do you have git integrated in your editor so you have git-blame-style commit messages next to your code? If that is the case, I guess putting the information in the commit messages makes sense.
No but blame is very close by and easy to access, so when I want to know why something was done that way it's not far away.
Comments keep getting out of sync, code gets inserted before or after, … and after a few years (or months on large codebases) it's just complete nonsense. I reserve them for stuff that's really super important to say right here (and todos).
You don't know the 'pleasures' of code archaeology? Sometimes you are digging into ancient code, written by somebody that is no longer around, trying to figure out why something is the way it is. Why did this business rule change? Why was this line added? A good commit message will explain the "why" of the change.
I use them for
- Tracking work on specific jira tickets
- Giving myself a simple/quick overview on what was done
- Tracking down bugs by trying to understand if that code is doing what it should do (bug vs. on purpose)
- If i need to revert something, i revert a git commit. might just happend once a year but if required its fundamental
I'm also always slightly surprised about discussions from this topic: Its a nobrainer to just do it.
Its cumbersome if you have to explain to colleges, who are working with code for longer then a few month, why you should just write proper git commits.
It is like 'i'm allowed to write code which does a lot if things but pls exlpain to me again how i write a proper git commit message' :(
All the time. I work with a team that pretty much agrees on commit message detail and format. It is so nice to have all changes documented with the "why".
We keep as much of everything as possible in Git, including configuration. I can look back to every time we've adjusted the memory of a service, every time the number of instances has changed and have descriptions as to why that was done, associated tickets, etc.
Another great reason is integration with hosted Git tools. I know that Bitbucket and Github (and likely many others) will populate a pull request title/description with the commit message. Putting all of the necessary background in the commit message is a great way to supply the reviewer with information surrounding the commit, which decreases turn-around time for PRs. That history and reasoning is now ticketing-system agnostic and available in all of the popular editors that I've used (Vim, Emacs, VSCode, Intellij).
The most recent commits are a load of merges, but the slightly older ones have very long commit messages. The first one I clicked [1] has 11 changed lines of code, and a 32-line commit message.
It all depends on how well you use git I guess. Imagine you developed a feature on a branch, then merged it into main. Later you have to change something at that feature, from the commit message you can find the commit, then you can see which parts of code is effected by that.
Then you are working on a subset of code, and can see of your change is effecting something else, or where else you need to make changes.
Or maybe someone fixed a bug there, then from commit message you can go to related bug, see their intentions more clearly.
When you share code with other people, "your" code gets updated continuously. In that context, you often want to know what motivated an update, and how it may affect what you are doing.
Consider a bug fix, you want to know what was the bug, and why the fix is actually a fix. This is complementary to comments which don't tell anything about the code evolution.
A good commit message can save a lot of work to your colleagues and even yourself in the future.
I think it depends on the project and the culture of the team. If they're there they can be handy, but it really only works if everyone is disciplined about it so it becomes a reliable source of information. If, on the other hand, half the commits in the repo just say "fixes," you get in the habit pretty fast of digging through code via other means first.
If you work in projects with a hundred other engineers or projects with maintenance, then there is no way you can get a sane code base without commit messages and reviews.
However, if you work alone and do not need maintenance, then yes, they are pointless since you will never need to read them.
It depends. if you've just fixed a fairly obvious bug then no but if you're (for example) merging something like ebpf into the kernel then expect to be writing a fairly large commit documenting how, why, where etc.
I would be curious to hear how others view this.