Live data from Hacker News

My favourite Git commit (2019)

dhwthompson.com

11–20 of 406 posts

Re: My favourite Git commit (2019)

#11

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.

>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.

Re: My favourite Git commit (2019)

#12

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 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.

They have value even if the only person who will ever look at them is you - and I will say that when bisecting an issue, the commit message of the commit I finally find is really useful (or it could be if it wasn't fixed thing). It also means that if you encounter a similar issue again, you know that there's a note on a commit you can find.

Re: My favourite Git commit (2019)

#13

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.

For a long time there was a Perl script called the Demoronizer that fixed this kind of nonsense.

Re: My favourite Git commit (2019)

#17
post #3

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 find myself commenting code in a similar pattern: A small kernel of "interesting" code that has a 1:1 ratio (or higher) of comments to code, which enables the rest of the codebase to be "boring" self-documenting boilerplate-y code that doesn’t really warrant much in the way of commenting.

Re: My favourite Git commit (2019)

#18
post #12

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 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. They have value even if the only person who will ever look at them is you - and I will say that when bisecting an issue, the commit message of the commit I finally find…

In some orgs, people never run a bisect. Not once a year.

They go as far as squashing out swaths of history into big un-reviewable blobs. Once code has been merged, they never look inside a past commit again.

In spite of isolated (desperate) demands for rigor, it works fine.

Re: My favourite Git commit (2019)

#20
post #3

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 `…

For a commit that adds a language binding (and might be 100+ additions/deletions) I might just say “Add X function”. Because I’m just following established patterns. But for the linked kind of change? Yeah, several paragraphs of explanation is definitely useful.
Post reply on HN