Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My favourite Git commit (2019)

dhwthompson.com

Post reply on HN
Print view View original

51–60 of 406 posts

Re: My favourite Git commit (2019)

#51

Post by jboy55 »

karagenit wrote: post #6
aeurielesn wrote: post #2

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.

Yeah, I've been bitten by those quotes in the past too. I noticed recently that VSCode (probably other IDEs too) highlight these characters pretty clearly to help avoid these issues.

I wonder how much infighting there was between orgs at Microsoft over this. with an Outlook/Word PM escalating... "Make the languages understand smart quotes!"

Re: My favourite Git commit (2019)

#52

Post by 20after4 »

spenczar5 wrote: post #5

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 might be weird but I try to at least skim all of the commits on any project I am actively involved with. If it's an open source project then those commit messages will live on forever. They will even be indexed in regular search engines, not just code search (this maybe not so much now that GitHub is locking out bots more and more)

When I'm trying to solve a problem and not finding results on google or stack overflow, sometimes I search GitHub just to see if a similar thing shows up in PRs or commit messages anywhere (including private repos I have access to search). It's helped me out on countless occasions. Good commit messages do have value beyond vanity, absolutely without a doubt. The fact that many developers aren't looking, that's their loss and hopefully they will see the light once they have enough experience. Maybe teach a junior dev how to search them! Maybe link them to TFA.

Re: My favourite Git commit (2019)

#53

Post by slily »

spenczar5 wrote: post #5

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 agree this one goes into more detail than is useful for future reference, most of the explanation would be better off in a PR description. But in general I would rather people go into too much detail than the more common variant of not providing any contextual information anywhere (or only in a chatroom at best) and sticking to one-line commits. As long as the important information is near the top so I don't have to wade through the verbose "this is how I discovered this issue" thing, go crazy.

Re: My favourite Git commit (2019)

#54

Post by mbork_pl »

maleldil wrote: post #35
mbork_pl wrote: post #30

Earlier quoted context omitted.

How do you handle non-paired ones then?

Render them as standard double quotes? The same way Markdown renders a single backtick as just a backtick, but text surrounded by backticks becomes code.

Nice try, but the problem with this is that typography is _really_ complex. For example, there is a rule in English typography (I'm not sure if it's often used today though) that when you have a quotation spanning several paragraphs, you should put an _opening_ quote at the beginning of each paragraph – but only one _closing_ one at the end of the quote.

Re: My favourite Git commit (2019)

#55

Post by karmajunkie »

andrewfromx wrote: post #33

I stated using gofakeit's "hackerphrase" for all commit messages. https://github.com/andrewarrow/feedback/commits/main/ hp | git commit -a -F - hp is a golang binary that just spits out a hacker phrase. I have this aliased with the letter q for "quick" so I'm always checking in stuff with q return push done.

I've been using opencommit[1] and have been pretty happy with the summaries its generating. I usually add a one liner at the top to summarize the reason for the PR but it saves me a lot of typing documenting what was actually done at a high level.

[1] https://github.com/di-sukharev/opencommit

Re: My favourite Git commit (2019)

#56

Post by gtirloni »

Great commit indeed. lots of context information. that's gold.

The worst I've seen are dozens of tiny commits pushed to the master branch directly. If you want to find out what took to implement a feature, good luck.

I'm a fan of tiny commits during code review but afterwards I prefer to squash everything in a functionally relevant commit. It makes git archeology much easier.

Re: My favourite Git commit (2019)

#57

Post by bspammer »

tuetuopay wrote: post #45
tux3 wrote: post #18

Earlier quoted context omitted.

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.

I despise squashs. It encourages people to tread git commit as a glorified ^S of their work. You want to know why a change was made, or who so that they can explain it. You land on a blob of a diff, with no meaningful commit message (any commit message was squashed to /dev/null to be replaced with the MR title and description). And then off you go to the corresponding github/gitlab/whatever MR only to find a wall of…

This is a false dichotomy. Someone creating the "fix problem" commits is not going to suddenly write great commit messages because the merge strategy changed.

The root evil is actually MRs that live longer than a day or two, and change too much code at once.

Re: My favourite Git commit (2019)

#58

Post by masklinn »

ajuc wrote: post #41

I agree commit messages are the most important form of documentation. But I disagree about the format. I prefer commit messages like: JIRA-123 one-line 80-char-at-most description Long description if needed (but preferably keep it in JIRA).

> but preferably keep it in JIRA

Jira is an additional indirection to a tool you will (not might) eventually lose. I’ve seen commits which had lived through 3 VCS transitions.

Not only that, but a lot of information is often considered undesirable on tickets.

Re: My favourite Git commit (2019)

#59

Post by adamsilkey »

tuetuopay wrote: post #45
tux3 wrote: post #18

Earlier quoted context omitted.

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.

I despise squashs. It encourages people to tread git commit as a glorified ^S of their work. You want to know why a change was made, or who so that they can explain it. You land on a blob of a diff, with no meaningful commit message (any commit message was squashed to /dev/null to be replaced with the MR title and description). And then off you go to the corresponding github/gitlab/whatever MR only to find a wall of…

Squashes and rebaseses, used properly, are done prior to committing work into a shared major branch (like trunk or develop or whatever). The goal of the squash is to make the resulting commit atomic.

Re: My favourite Git commit (2019)

#60

Post by fusslo »

marcosdumay wrote: post #37
fusslo wrote: post #25

great commits are great. This is fantastic As an aside, I'm tired of documenting: - in code - in commits - in jira - in confluence - in daily standups - in release notes

The code and commit documentation are about different things. One is about what this thing is, the other is about what is changing. But then, jira is about what is changing, confluence is about what is changing, standups are about what is changing (oh, but this is doing them wrong), and release notes are about what is changing. So your complaint is completely reasonable, just the first item shouldn't be there.

I dont think Ive worked at a company that used commit messages to record what is changing.

Im not saying that I am disagreeing with you on that point. I’m just sharing my experience

We tend to rely on the diff and PR for the ‘what is changing’

The PR doesnt list the commit messages anyway, just the last commit message and the PR description

We add links to jira/confluence a lot in code to give direct access to the dev. Commits are tied to features or bugfixes

So effectively commit messages are not useful anymore

The only one that might be useful is the merge commit message

Again, not disagreeing, just complaining lol

Post reply on HN