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

31–40 of 406 posts

Re: My favourite Git commit (2019)

#31

Post by anthomtb »

bombcar wrote: post #12
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 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…

I agree with this wholeheartedly. If writing a detailed, multiparagraph commit message, assume the target audience is future you.

Most likely, a time-pressed dev on the far side of the world will think your commit broke something and send a 2:00 AM message of "URGENT: code broke CRITICAL customer request" with a link to the commit, whatever JIRA issue they are working on, and zero additional context. They will NOT bother to read the message (likely explaining how they got into their pickle in the first place) but will see your email, send a message, and do whatever it is they do while waiting for someone else to figure out the problem. You, being that someone else, will now have an excellent starting point on the top priority for the day. Much better than if your message had just been "fixed it".

Re: My favourite Git commit (2019)

#32

Post by macintux »

adrianmsmith wrote: post #24

I think the disadvantage with this style of documentation is you can't really alter the commit message after it's written. (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 colleag…

There's no reason this documentation can't be replicated in another context, and for all we know it was.

Re: My favourite Git commit (2019)

#33

Post by andrewfromx »

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.

Re: My favourite Git commit (2019)

#34

Post by tyrust »

adrianmsmith wrote: post #24

I think the disadvantage with this style of documentation is you can't really alter the commit message after it's written. (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 colleag…

I think commit messages are mostly valuable for a future code reader asking "why is this bit like this?" and then looking at blame logs for the answer. As you point out, bigger picture stuff ought to be elsewhere (documentation, tracking bug).

Keeping docs in version control and including doc changes with the code changes is a nice way to address your concern.

Re: My favourite Git commit (2019)

#35

Post by maleldil »

mbork_pl wrote: post #30
atahanacar wrote: post #28

Earlier quoted context omitted.

Why not stylize it as typographic but store it as a "regular" double quote though?

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.

Re: My favourite Git commit (2019)

#36

Post by WalterBright »

At the DLF, our pull requests are usually accompanied by a link to the bugzilla entry, which usually have a detailed explanation.

P.S. Having multiple Unicode values that exhibit identically when displayed are a huge veer-into-the-ditch mistake. I.e. the notion that code points should have semantic value is simply wrong.

Re: My favourite Git commit (2019)

#37

Post by marcosdumay »

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.

Re: My favourite Git commit (2019)

#38

Post by josephg »

adrianmsmith wrote: post #24

I think the disadvantage with this style of documentation is you can't really alter the commit message after it's written. (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 colleag…

I really think git made a mistake in conflating the immutable log of what was changed with the (ideally mutable) story of what got merged in. So you see people arguing over squashing commits vs rebasing vs merging. Squashing commits makes the history of commits a better story of features being added. Merging preserves the immutable log of the actual changes made to the code, and rebasing sort of does a bit of both.

But, I don't see any reason we can't have our cake and eat it too. We're programming computers after all and we can make them do whatever we like.

If I wrote my own git, I think I'd split commits into those two parts. I'd leave the history of changes immutable - probably with some sort of Merkle DAG like Git does. And then have a separate associated data store which stores the commit messages, in a nice sensible, editable log describing the work that actually happened. Let people arrange and rearrange the commit descriptors however they like. If you want, group commits around feature tags, fix typos and make any changes to the messages that you want. But, the whole while the underlying log of diffs ("what actually changed in the code") can remain (gloriously) unaffected.

Re: My favourite Git commit (2019)

#39

Post by ryanisnan »

adrianmsmith wrote: post #24

I think the disadvantage with this style of documentation is you can't really alter the commit message after it's written. (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 colleag…

I think the non-editable nature of commit messages is precisely the benefit though. Yes, you can't really modify them post-hoc, but being able to step through a code base's history can be really illuminating.

Re: My favourite Git commit (2019)

#40

Post by Lex-2008 »

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 was bitten by too-short commit messages few times already, when someone asks me "why is it done this way?" - I check git history to find my own 3-year-old commit with message "it should be done this way"... Since then I try to write my commit messages so at least future me would get a hint why a change was necessary.
Post reply on HN