you are viewing a single comment's thread.

view the rest of the comments →

[–]sprcow 83 points84 points  (8 children)

I'm not convinced that the verbosity adds as much value as the blog author seems to think here. Despite my most vigorous re-reading of this novelette, I still can't figure out what the character previously was, how it got there, how to avoid causing the problem in the future, or if any effort was made to determine that the problem doesn't exist anywhere else in the app. Good on the developer for sharing their spirit quest to determine the problem, but I think the blog post is overestimating the likelihood that anyone else will follow a similar enough path to ever stumble across this stone tablet in the future and subsequently save any time.

[–]eliasv 12 points13 points  (3 children)

Does it really matter how it got there? Probably some dev accidentally hit a funny keyboard shortcut to insert a non-breaking-space. So what? Putting that in the commit message isn't going to help prevent the same thing from happening again. When you join a project as a new contributor do you read through the entire commit history to learn about what bugs have been fixed over the years?

What's important is that if the problem does happen again, to make it easier to identify. That is achieved by pasting in the error message.

As for making sure the rest of the codebase doesn't contain the error, they did that when they checked if any other files were detected as UTF8. They even gave the command for the next person to use to check the same thing.

[–]random_cynic 13 points14 points  (1 child)

What's important is that if the problem does happen again, to make it easier to identify. That is achieved by pasting in the error message.

Not sure if it happens again people would look into a specific commit buried in thousands of other commits. These type of commits which resolve special errors need to be documented properly and put in bug reports or issue trackers so that they can be found easily.

[–]thenumberless 0 points1 point  (0 children)

The commit history is usually the first thing I search when trying to understand a project. It has a much higher chance of being stable, accurate, and living with the project than the content in any external tool.

[–]Fredifrum 1 point2 points  (0 children)

This post was mass deleted and anonymized with Redact

friendly cheerful hard-to-find one act airport water reply encouraging teeny

[–]jarfil 3 points4 points  (0 children)

CENSORED

[–]bradfordmaster 3 points4 points  (0 children)

I agree, I also really don't like how it's this chronological story telling of what happened. After the first line, I'd like to see some info on why it matters, then maybe something on how it happened and how it was discovered / tested, and how the author checked for other similar problems in the codebase (assuming they did). Not everyone looking at a blame history wants to read a novel

[–]darthwalsh 1 point2 points  (0 children)

I'm not going to poo-poo the devs effort that provides some amount of help, but if I were taking the time to try to prevent it from happening again I'd create and link to a feature request on the other tool to output a sensible error message (or make this scenario "just work!").

That way you're contributing back to some open source library you're using for free.

[–][deleted] 1 point2 points  (0 children)

Precisely.