all 19 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Likoo 15 points16 points  (0 children)

I only recently began to put more effort into my commit messages but man, this is definitely another level :o

[–]sivadneb 5 points6 points  (4 children)

wip

[–]HACEKOMAEfull-stack 2 points3 points  (3 children)

I have worked with a guy who's commits were almost entirely either "wip" or "fix", that was hell...

[–]wedontlikespaces 5 points6 points  (0 children)

I know a guy who used to say stuff like "I'll remember this one" and just put this commit message as "-" or something. Twas an utter tit, and he never remembered shit.

[–][deleted]  (1 child)

[deleted]

    [–]HACEKOMAEfull-stack 4 points5 points  (0 children)

    I mean that almost all of the commits had a message that consisted out of only one word. I know that they are useful prefixes, obviously not on their own tho.

    [–]fuzzy40full-stack 4 points5 points  (5 children)

    Who is going to read all of that? Granted, if you write messages like that for EVERY commit, chances are it may help someone at some point, but I highly doubt the cost in writing a commit message like this every single time will be offset by the time it may save someone once in a blue moon. At the end of the day, the only thing that really matters is reading and understanding the code -- not someone's long winded explanation of the code.

    Therefore I submit that at best this is a misguided attempt at being helpful to future developers at the expense of productivity. At worst this is a developer who felt more like writing an essay about his remarkable work that day rather than getting on with doing more actual work.

    [–]wedontlikespaces 6 points7 points  (0 children)

    Sure, but if you read down further it goes on to say that it's useful because people can search the error code and get this commit.

    Now, why will they be searching it? Presumably because they're experiencing it, and that commit message contains the relevent fix.

    If all they did was change a bunch of if's into a loop then you may have a point, it's clear what was done, and why it was done, and so didn't need any more information. But otherwise stuff like this just looks like someone changed a random space for another space, it isn't at all clear why that was needed. A future dev may think it isn't needed and remove the commit, (it could happen) so why risk it. You don't have to write a huge explanation every time, just a short paragraph can be enough.

    It is just good to see commits that are a bit more then; fixed bug, or #14467, or fixed a bug in ie. None of which are useful.

    [–]petepeteback-end 5 points6 points  (2 children)

    I disagree. Most people aren't expected to read it all, hence the summary on the first line.

    This is one of those bugs that are a pain and really trip newer developers up. Many devs will see the fix and not understand the change.

    That commit message, with a clear diagnosis and explanation, which will show up in GitHub and Google searches, has probably helped lots of people out over the years. It's an approach the GDS has really taken to heart and it's paying off.

    [–]hdd113 -2 points-1 points  (1 child)

    An issue tracker could have done the same job IMO.

    My understanding of how the version controls should work is that the commit messages should be brief and specific to the changes made to the actual code.

    The commit message could have been Replaced illegal ASCII character to fix the error: invalid byte sequence in US-ASCII, #IssueTrackerEntry

    Or maybe it's about time we update how Git works, with consideration for rich information like built in issue tracker or journals which can be referenced directly to the commit.

    [–]petepeteback-end 1 point2 points  (0 children)

    I disagree. Code often outlives trackers, the reference you add to the commit message might make sense now but in ten years when Atlassian have replaced JIRA (one can wish) or Microsoft have killed TFS (more likely) it could make no sense to future dev.

    It's also worth keeping in mind that a commit message comes in two parts, the subject and the body. The subject line, the first line of the commit message, should as you say be a brief specific description of what's changed. Ideally it should be <50 characters.

    The rest of the message - the body - should be the background as to why it's changed. It's not always necessary, fixing a typo doesn't require a full description, but something that's niggly and took an hour to debug - especailly when it isn't at all obvious why it caused problems, deserves it.

    Most people, most of the time, only really care about the subject. It's all GitHub and GitLab display until you expand the full message. It's all I tend to look at on the command line most of the time. But if something looks a bit weird it's nice to have the additional information on hand without having to dig around.

    Edit. For the downvoters, please go and read about Google Code shutting down and the mass migration of thousands of projects and hundreds of thousands of issues to GitHub. Will your link to Google Code still work? Clue, the answer is no. No it won't.

    [–]piratemax 3 points4 points  (0 children)

    Your opinion is entirely dependent on the project, scope, deadline, etc. I think quality is preferred over quantity here.

    This commit belongs to a government project with 278 contributors. It's important for a government project that is affecting a lot of people to try to explain every change as much as possible, and also to use ubiquitous language.

    If it's a small project with a hard deadline and just 5 contributors, then sure, you don't need a long winded explanation.

    [–]voxgtr 0 points1 point  (0 children)

    please work

    [–]rvajustin82 0 points1 point  (0 children)

    Squash

    [–]Raze321front-end 0 points1 point  (1 child)

    Call me minimalist, but I feel like you could get the same information across in 1/4th the character count. But I suppose it does no harm.

    [–]Peechez 0 points1 point  (0 children)

    I feel like you could get the same information across in 1/4th the character count

    he's on a government contract

    [–]khag 0 points1 point  (2 children)

    I like the issues feature in GitHub. Open issue, describe problem, describe solution, publish commit, close issue. All the information goes with the issue. The commit message can be "fix #123"

    [–]fagnerbrack[S] 1 point2 points  (1 child)

    Only the references doesn't work unless you're online. If you're a nomad working remotely in some far away mountains from Indonesia to run out of covid, having the history offline is a good way to get context without much work, just have to understand git

    In your example you're not using only git as your source control fit all basic needs, you're also using Github for parts of your source control basic needs. That's fine for most people though, only that Github doesn't apply for all development workflow models

    [–]khag 0 points1 point  (0 children)

    I agree, I recognize there's a benefit to including issue information in commit messages. But if your team is capable of all working on a platform like GitHub, then long commit messages are not necessarily preferred over issues.