The author spent all the time documenting his journey but totally fails to explain the actual reason of the problem: If the file contains a UTF-8 byte sequence, why is there an attempt to parse it as US-ASCII? I get that it's just a wrong space, but if some day somebody actually want to put a UTF-8 char there for some reason, this commit essay wouldn't help at all whereas googling stackoverflow seems to deliver (unverified):
<a href="https://stackoverflow.com/questions/15947425/rake-tasks-fail-with-invalid-byte-sequence-in-us-ascii" rel="nofollow">https://stackoverflow.com/questions/15947425/rake-tasks-fail...</a>
I'm just curious but... did this actually fix anything other than the spec?<p>The reason I ask is that I find myself (with Rails particularly) spending an awful lot of time on maintaining tests that were written by a much younger and much less experienced developer (me, a few years ago).<p>And I've come to the slow realisation that a lot of what I was testing wasn't really important.<p>I'm not saying the author shouldn't have written the spec, or that the spec wasn't valuable. But maybe the true bug here was that rspec matchers don't honour utf-8 spaces and perhaps they should? I dunno. Just thinking out loud here.
I, too, use git commit messages to document the reasoning behind my changes. But I'm unsure if my colleagues even notice, since they regularly write bad commit messages like "Fix bug" and things like that. Also I regularly find my commit messages got lost, since the reviewer squashed several commits into one.<p>Do you have any tips for establishing a culture of good commit messages?
Previously: <a href="https://news.ycombinator.com/item?id=21289827" rel="nofollow">https://news.ycombinator.com/item?id=21289827</a> (domain has changed since the last post)
I do love the social history of good commit messages, and what they teach us about the process of what we do.<p>I will offer one nit here, which is that I <i>always</i> start my commit messages with one-line summaries; this makes it really easy to scan commits (and git is tooled to do this!)
I wonder: what is the bad character? It's apparently not 0x20, but what is it? How did it get there? What keeps this from happening again to someone else?
What's the latest on how long a commit message should be? Used to be everyone said a message should never be longer than two sentences and that they should be as short as possible so that people actually read them. This thing posted is an essay. Not the haikus I thought was considered best practice.
Linking to the mpv commit[0] message brought up in the last discussion[1]. It’s absolutely hilarious, and a great example of someone rage typing after dealing with an issue.<p>[0] <a href="https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe" rel="nofollow">https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...</a><p>[1] <a href="https://news.ycombinator.com/item?id=21290517" rel="nofollow">https://news.ycombinator.com/item?id=21290517</a>
My personal favourite commit (as opposed to commit message) <a href="https://chromium.googlesource.com/crashpad/crashpad/+/badfacccee" rel="nofollow">https://chromium.googlesource.com/crashpad/crashpad/+/badfac...</a><p>(Sadly, the commit message isn't great, but clearly it's worth that hash.)
Please do not do this. Long essay style commit messages are not really searchable, have no real way of discussions, do not support formatting, images etc and are hard to even read in many tools. A better way is to create an issue first and attach it to your commit.
This is my favorite git commit:
<a href="https://android-review.googlesource.com/c/platform/system/bt/+/1241366" rel="nofollow">https://android-review.googlesource.com/c/platform/system/bt...</a><p>result:<p><a href="https://android.googlesource.com/platform/system/bt/+/refs/heads/master/gd/README.md" rel="nofollow">https://android.googlesource.com/platform/system/bt/+/refs/h...</a>
That's just way too verbose though. There should have been a ticket with a description of the problem. Name the branch after the ticket and jira will automatically link the ticket to the commits that fixed it.<p>I've encountered bad utf-8 when data is copied from excel or outlook.
Can someone comment on a best practice whereby the commit might merely refer to the problem ticket (in whatever system), which should have all of the relevant problem histories, and the articulation of the solution? As opposed to all of this documentation in git?
It's not only about the fact that the commit message for a one char change is about a page long. It's about that all the information in that page long commit message is a useful information
Paraphrasing the first comment of the commit[1]:<p>A commit message with such a long explanation helps nobody, because it is not searchable by Google, not even by GitHub[2]. [...] If the commit message requires a blog post to be good (searchable) – it is a poor commit message.<p>[1]: <a href="https://github.com/alphagov/govuk-puppet/commit/63b36f93bf75a848e2125008aa1e880c5861cf46#commitcomment-35571322" rel="nofollow">https://github.com/alphagov/govuk-puppet/commit/63b36f93bf75...</a><p>[2]: <a href="https://github.com/search?q=invalid+byte+sequence+in+US-ASCII&type=Commits" rel="nofollow">https://github.com/search?q=invalid+byte+sequence+in+US-ASCI...</a>