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

How to write a Git commit message (2014)

cbea.ms

Post reply on HN
Print view View original

171–180 of 185 posts

Re: How to write a Git commit message (2014)

#171

Post by Mawr »

tjr225 wrote: post #103
scoot wrote: post #65

Earlier quoted context omitted.

Yes. Are you?

Yup, you should re-evaluate. There are a jillion reasons to do things that are chores. The word chore should not be implicitly perceived as a negative thing. Do I want to clean my house? Yes. Is it still a chore? Do some thinking for yourself. I honestly have no idea what the heck you are talking about; hence my comment. Do you seriously perceive any chores as not worth doing? That sounds unhealthy.

> There are a jillion reasons to do things that are chores.

> Do I want to clean my house? Yes. Is it still a chore?

> Do you seriously perceive any chores as not worth doing?

None of these are relevant as to whether 'chore' has negative connotations.

It clearly does to me and I'm baffled at the opposition. Do I want to clean my house? No of course not, and you don't either. If your house cleaned itself automatically would you still wish to do it? No, you do it because you need to, not because you want to.

Just about every dictionary definition mentions chores as at least possibly considered negative:

> a hard or unpleasant task: Solving the problem was quite a chore.

([1])

> A chore is a task that you must do but that you find unpleasant or boring.

> She sees exercise primarily as an unavoidable chore.

> Making pasta by hand with a rolling pin can be a real chore.

([2])

An entire article that wouldn't exist if chores were fun activities: [3].

> “Chore” can have a negative connotation and feel like a burden to a child.

[1]: https://www.dictionary.com/browse/chore

[2]: https://www.collinsdictionary.com/dictionary/english/chore

[3]: https://www.nspt4kids.com/parenting/take-the-chore-out-of-do...

Re: How to write a Git commit message (2014)

#172

Post by scoot »

imwillofficial wrote: post #88
scoot wrote: post #76

Earlier quoted context omitted.

> It means a code change that you do regularly but is not major So "update". Attaching emotionally charged words like "chore" does nobody any favors, and in fact has negative consequences.

It sounds like you have attached negativity to a relatively harmless word.

Let's just say that one of us is speaking English, and the other thinks that they are.

Re: How to write a Git commit message (2014)

#176

Post by tjr225 »

Mawr wrote: post #171
tjr225 wrote: post #103

Earlier quoted context omitted.

Yup, you should re-evaluate. There are a jillion reasons to do things that are chores. The word chore should not be implicitly perceived as a negative thing. Do I want to clean my house? Yes. Is it still a chore? Do some thinking for yourself. I honestly have no idea what the heck you are talking about; hence my comment. Do you seriously perceive any chores as not worth doing? That sounds unhealthy.

> There are a jillion reasons to do things that are chores. > Do I want to clean my house? Yes. Is it still a chore? > Do you seriously perceive any chores as not worth doing? None of these are relevant as to whether 'chore' has negative connotations. It clearly does to me and I'm baffled at the opposition. Do I want to clean my house? No of course not, and you don't either. If your house cleaned itself automatically…

I only got a few sentences into this but I can assure you that I love cleaning my house, and performing various other chores. Work related and otherwise.

If I didn’t do them, my life would be worse than if I didn’t! It’s pretty easy stuff! Embrace the chore, clean up after yourself! It’s worth doing.

Re: How to write a Git commit message (2014)

#177

Post by mwt »

tremon wrote: post #158
wdroz wrote: post #124

Earlier quoted context omitted.

Fastapi use gitmoji [0], this is well-documented and structured. [0] -- https://gitmoji.dev/

That's... horrible. You mean the entire developer's thought process behind a change will be represented by a single 12x16 picture? Even hieroglyphs were more expressive than that.

> You mean the entire developer's thought process behind a change will be represented by a single 12x16 picture?

No, look at the log of FastAPI (or even gitmoji itself: https://github.com/carloscuesta/gitmoji) and you'll see that i.e. the bug emoji serves *only* to replace "bugfix: " at the beginning of the commit message, not the entirety.

Re: How to write a Git commit message (2014)

#178

Post by twhitmore »

darkerside wrote: post #150
twhitmore wrote: post #114

Interesting topic. From my experience Headline + Bullet Points are far quicker to convey useful information, in a form that is terse yet easy to read. For example: ---------------- improve Buffer Cache Management & logging - change 'tryDrop()' to skip immediately, if lock unavailable - move BufferCache logging to a separate logger - attach BufferTrim.Unsuccessful -> Preemptive Flush of oldest buffers ----------------…

Just thinking out loud, but wouldn't this be best handled with separate commits for each of these atomic changes, with a merge commit describing the intent ins narrative form? Don't ask me if I practice what I pushed there

Good question. The example message is adapted from a fast-moving innovation stream; it's an example of moving quickly and getting a lot of major work done.

In a more mature area, pace of work could often be slower and commits more granular. Until it's necessary to refactor/ reengineer things -- then commits are often larger again.

That's been my experience anyway, YMMV.

Re: How to write a Git commit message (2014)

#179

Post by kgeist »

atq2119 wrote: post #170
kgeist wrote: post #163

Earlier quoted context omitted.

I view the commit message first, of course, and only if it's not enough, I go to the issue tracker. >That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate Interesting, just for the sake of it, I measured how much screen space the issue ID takes up on my monitor with my current font settings - around 5% (of monitor width, of course). Never been a problem for…

If you view the commit message first, then I don't see how having the issue ID as the first thing helps your git blame use case. You can see the issue ID just as easily in a footer line of the commit message. As for screen space, one of the standard email client layouts has a vertical split, with message titles on the left and bodies on the right. This generally fits well with 16:9 screens, but the line width for tit…

As long as the issue ID is somewhere in the message, I'm fine with it :) But, for example, yesterday I was cherrypicking many small commits pushed by a junior dev to wrong branches and it greatly helped that it comes first, there's less mental burden, it's easier to spot. We also have a tool which checks issue IDs in commit messages against the issue tracker (various custom states in our flow) and, again, it's more robust and simpler to implement if there's a standardized place where to put your issue ID.

Re: How to write a Git commit message (2014)

#180

Post by salamander014 »

ufo wrote: post #31

I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.

I try to subscribe to the idea that if you cannot adequately describe your commit in a small number of characters (~50 is plenty I feel), your commit is likely too complicated. One size does not fit all, and if a workflow ain't broken there's usually no need to fix it. However most workflows are imperfect, there is almost always room for improvement.

But in the general case I find that if commits are not themselves concise and simple changes, they often should be broken up so that the moving pieces can be better tracked when looking back at the history.

Post reply on HN