21–30 of 406 posts
I had a terrible time when someone used "smart quotes" (beautified Office quotation marks) in a configuration file. I believe this was only possible because they copied it from Outlook.
One thing I disagree with is: > I wouldn’t expect all commits ( especially ones of this size ) to have this level of detail. (emphasis added) - actually in my experience it's often the little ones, innocuous looking things that might really need a relatively longer explanation. Yesterday I wrote three paragraphs on why I added `--limit=999` to a `gh pr list` because it's confusing: there's already a `limit(` in the `…
> This was a non-ascii whitespace character that caused `ArgumentError: invalid byte sequence in US-ASCII` when running `bundle exec rake`
^ should be sufficient. It includes enough keywords to come up in a search if someone has a similar problem in the future, it contains the root cause of the problem, and it is short enough that people are unlikely to gloss over it.
I have felt that pride in writing a great commit message, but I am less sure of the value to others. I don’t think most people search commit messages when they encounter an unusual error message, or when adding a new feature, or really almost ever. It’s a bit sad, but I have a growing suspicion that beautiful commit messages are a bit of vanity by the programmer. The person primarily impressed is often the author; ot…
(I mean you could obviously with "rebase" but are you really going to alter something written one year ago, already merged to "main", and cause a bunch of pain with everyone's feature branch etc.?)
Compare that with documentation stored in a .md file, or even a Wiki or even Confluence. My colleague can write something and if I see a way to improve it I can go ahead and do that, and other colleagues can improve on what I've written.
In this particular case I suppose the bug is fixed and won't come up again. But I also myself find it tempting to describing the design of a particular component when I commit that component, and that's something I now avoid. What about when that component needs to be changed by a future commit e.g. due to the business requirements changing? Will the commit documentation just describe the differences? Then in order for a new team member to find out how the system works by reading the documentation they've got to read multiple commit messages and "merge" them in their head.
As an aside, I'm tired of documenting:
- in code
- in commits
- in jira
- in confluence
- in daily standups
- in release notes
I had a terrible time when someone used "smart quotes" (beautified Office quotation marks) in a configuration file. I believe this was only possible because they copied it from Outlook.
I think this pops up in MacOS shells too
Tells me exactly what the problem was straight away, but I'm still free to choose to read more if I want to know more.
Earlier quoted context omitted.
>smart quotes I never understood why a "stylistic" choice requires separate characters. If we don't need a serif and non-serif version of every character and instead leave it to the software, why can't we do the same with the "smart" quotes?
Typographic quotes are left- and right-handed, vs. the ASCII double quote which is just a single character: “quoted” "quoted" Who in the blazing highs of techno-utopianism fervor thought it was a good idea to automatically translate the latter to the former we'll never know.
One thing I disagree with is: > I wouldn’t expect all commits ( especially ones of this size ) to have this level of detail. (emphasis added) - actually in my experience it's often the little ones, innocuous looking things that might really need a relatively longer explanation. Yesterday I wrote three paragraphs on why I added `--limit=999` to a `gh pr list` because it's confusing: there's already a `limit(` in the `…
I agree with you that the little innocuous things often need a longer explanation, but the linked commit message is way too long IMO. It either wastes the readers' time, or it causes the readers' eyes to gloss over at the wall of text. You don't need to document your entire journey in order to document your findings and explain why. > This was a non-ascii whitespace character that caused `ArgumentError: invalid byte…
Earlier quoted context omitted.
Typographic quotes are left- and right-handed, vs. the ASCII double quote which is just a single character: “quoted” "quoted" Who in the blazing highs of techno-utopianism fervor thought it was a good idea to automatically translate the latter to the former we'll never know.
Why not stylize it as typographic but store it as a "regular" double quote though?