91–98 of 98 posts
I really don't understand the reply in that thread, "what" doesn't matter because it's in in the code.
Of course it matters. The whole point is that you get your bearings from the comment text, and you only need to look at the code to see the details of the 'how'.
After being in the field for almost a decade now and guilty of so many poor commit messages, I came to the firm realization that a very important trait of a good software engineer is the ability and diligence to write detailed commit messages, and I would have never remotely imagined this during the first few years of my career (I was "raised" in companies who didn't care at all about this and all commits were always…
I've been a Software Engineer for 15 years now... 10 years in the industry as a systems engineer before that. I sort of agree but what I try to do is put more comments and documentation in the source code directly. The problem is that commit messages are usually hidden only when there's a problem. Comments are there for the life of the code. The problem with comments though is that they could go stale and something c…
Earlier quoted context omitted.
> "Moved A to B" is not necessarily bad There is always a reason why things are 1) done and 2) done in this specific way and not another. It is also relevant if this is part of a larger change and it there are external dependencies on this commit. These things must be clear from the commit message. > you're just doing janitor work That makes it sound like janitorial work does not require complete commit messages whic…
Git tools may be routed in email, but they most certainly aren't used that way by most people. Why would I write a commit message like I'm writing an email if both the commit message and email are the wrong tools for the job? We have issues are PRs for code discussion within the context of code. This priceless information should live with the repo. Not in some isolated silo like email which is not accessible to peopl…
Re: Email being an inaccessible silo: communities that use git-format-patch/git-am usually use mailing lists, which are archived, and subject lines have [PATCH] in them so searching needn't be difficult.
After being in the field for almost a decade now and guilty of so many poor commit messages, I came to the firm realization that a very important trait of a good software engineer is the ability and diligence to write detailed commit messages, and I would have never remotely imagined this during the first few years of my career (I was "raised" in companies who didn't care at all about this and all commits were always…
I think part of the issue is that for someone who's been writing English for 15 years, knocking out 2 paragraphs of cogent explanatory prose is as easy as ABC. But for someone who is relatively new to the English language, this can be the source of much anguish and frustration. Doubly so for something like a commit message that is immutable by design. The idea of a typo, a bad idiom, or even worse, unintentionally of…
Communication in software development is a huge deal. While language barriers are a thing, I don't think you can or should compromise on documentation, and when it comes to commit messages I don't think this is the leading reason why folks don't write good ones.
I'm told by friends who were at RedHat when they decided to make the source repositories public (as opposed to just throwing release tarballs over the wall), and commit messages went way way up. This tells me: people knew better, they just didn't care if they weren't being held to account.
That's a lovely description of why the fix was needed, but I just took a look at the go source, and NOWHERE IN THE SOURCE CODE IS THIS FACT DOCUMENTED. Signals are tricky, temperamental beasts; exactly the sort of thing you'd want to have comments about in your code. The way things stand, nobody would ever know why the signals are set up the way they are unless they trawled through 40,000 commits. Yes, 40,000: git lo…
Nowadays that I use VS code with GitLens, each line of code automatically shows me its latest commit message, just hover that info and I have the date, author and a link to the changes which usually give some useful context to understand why and how some particular line was edited. Very useful!
Too many times have I seen well documented code only to later realize that the code was edited with no updates to the comments, now useless and a source of time waste...
Earlier quoted context omitted.
Assuming you're doing Git based flow branching off of Develop or Master to do changes. Before merging your changes back in do you rebase and cleanup the messages or squash? I feel like every company I work for just does merges everywhere and history is 99% unreadable at this point without filtering out certain things on the log and even then. Any tips on how you're able to keep things clean for the entire team ? What…
We disabled merge commits on all of our repositories on Github, and rebase is used seldom - meaning that when you do merge you are presented with an edit box for the squashed commit message. This incentivises one to actually write good prose inside that box. We are not perfect but getting there.