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

My Favourite Git Commit

fatbusinessman.com

Post reply on HN
Print view View original

331–340 of 389 posts

Re: My Favourite Git Commit

#331

Post by nonconvergent »

zbentley wrote: post #164
deividy wrote: post #136

Earlier quoted context omitted.

"It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.", are you seriously?

Seems like they are. Also seems like a solid practice that far too many people ignore.

or you can say something equivalent yet unambiguous

A good commit message isn't about convention, and no convention makes a commit message good.

When I review a commit, I need only the information I won't get from the diff that I need to understand the context and the behavior.

My brainpower is a limited resource and extra noise in my signal is extra work.

I'm totally here for `ISSUE_123456 fixes defect` and `wip` are insufficient, but I'm not writing a code blog post in there.

Re: My Favourite Git Commit

#332

Post by webscalist »

navinsylvester wrote: post #108

I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…

Every commit message must start with JIRA ticket number

Re: My Favourite Git Commit

#333

Post by [deleted] »

twic wrote: post #188
beefhash wrote: post #101

I think my favorite (in terms of humor) is a commit from mpv complaining about locales and encodings. You can practically feel the committer's sheer frustration. [1] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

This message says much more about the author than it does about the commit.

[deleted]

Re: My Favourite Git Commit

#334

Post by johnisgood »

twic wrote: post #188
beefhash wrote: post #101

I think my favorite (in terms of humor) is a commit from mpv complaining about locales and encodings. You can practically feel the committer's sheer frustration. [1] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

This message says much more about the author than it does about the commit.

Really? I would say 90% of the commit message is technical, rest is just emphasizing his frustration, which is pretty much justified. Yes, he is a person that seemingly gets pissed off by bullshit design decisions and whatnot. So?

Re: My Favourite Git Commit

#335

Post by residentfoam »

In a professional context (and not only), one would think that this should be the normal expected good practice. But unfortunately, that is not the case.

It is so surprising (well not really) to see how, in most cases, developers put so little to close to zero effort in writing proper commit messages and more in general to have a clean commit history. They simply don't care and you keep seeing garbage commits with non-sense to close to empty message and description. Sadly enough this is seen as normal and just accepted.

Every single team I have been working with from small to large organizations I always had to pick up on the "write proper commit history" fight. And even after extensive explanations on why you should do that, people simply don't care and they keep pushing stuff like: "fix", "updated class z" and stuff like that.

Commit history does not seem to be part of the review process.

Sometimes it is just so depressing to see how so unprofessional software engineers are.

Re: My Favourite Git Commit

#336

Post by ImaCake »

residentfoam wrote: post #335

In a professional context (and not only), one would think that this should be the normal expected good practice. But unfortunately, that is not the case. It is so surprising (well not really) to see how, in most cases, developers put so little to close to zero effort in writing proper commit messages and more in general to have a clean commit history. They simply don't care and you keep seeing garbage commits with no…

If it makes you feel better, biologists are often no better. Our equivalent to git commits is labelling tubes and keeping little excel databases of what has gone where. Often databases stop being updated or people give their tubes esoteric labels that are meaningless to those who look at them a year later. As a research assistant in a large lab, I discovered blood tubes with literally no labelling, and often spent hours searching for samples in the labyrinth of freezers in that lab. It is also not uncommon for papers to be retracted because the original authors lost the raw data!

Re: My Favourite Git Commit

#337

Post by hyperpallium »

navinsylvester wrote: post #108

I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…

Formatted for my fellow HN-disenfranchised mobile sufferers:

Add = Create a capability e.g. feature, test, dependency.

Cut = Remove a capability e.g. feature, test, dependency.

Fix = Fix an issue e.g. bug, typo, accident, misstatement.

Bump = Increase the version of something e.g. dependency.

Make = Change the build process, or tooling, or infra.

Start = Begin doing something; e.g. create a feature flag.

Stop = End doing something; e.g. remove a feature flag.

Refactor = A code change that MUST be just a refactoring.

Reformat = Refactor of formatting, e.g. omit whitespace.

Optimize = Refactor of performance, e.g. speed up code.

Document = Refactor of documentation, e.g. help files.

Re: My Favourite Git Commit

#338

Post by sixstringtheory »

webscalist wrote: post #332
navinsylvester wrote: post #108

I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…

Every commit message must start with JIRA ticket number

I work at a place that used to prescribe this. I dislike it because it adds too much repetitive noise to the abridged git log. (It occurs to me that you may be making this point in a tongue-in-cheek way.)

Originally I suggested we put the JIRA number/link in the commit body, but then I learned about git-notes to add metadata to commits and now I kinda want to do this with the semantic labels suggested by the thread OP, too (I currently use the schema suggested at https://seesparkbox.com/foundry/semantic_commit_messages).

Re: My Favourite Git Commit

#339

Post by lugg »

blaisio wrote: post #328
navinsylvester wrote: post #108

I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…

Yes! I thought this was a great idea. The other thing I do is add a "MODULE:" prefix to my commit message. It makes them way more readable. Lots of other people do this too; you can see this in Redis, Linux, and Go codebases, for example. So your message might look like "router: add support for path vars". Much easier to read than "Add support for path vars to router"

Wanted to mention this.

I don't stick to it as a rule but if it's clearly grouped in some way it gives people in the wider org a high level fyi about the area of code you're messing with.

Makes it easy to jump over the commit when bisecting for regressions or hastily looking for the buggy commit to revert.

Re: My Favourite Git Commit

#340

Post by lugg »

navinsylvester wrote: post #108

I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing somethi…

Why? (Honest question, hear me out)

Is it a vocab consistency thing?

I see pretty consistent vocab used across orgs anyway, so given there is shardd domain knowledge / language at play, im not sure what the goal for standardization is?

Don't take this the wrong way, I use a lot of these when appropriate, but I don't think I could agree that refactoring must be just a refactor, and I don't think I want to limit anyone's commits to this list of change types either.

Forcing changes into these words means a lot of stuff is pointlessly bucketed when more appropriate wording could be used.

Say I want to push a commit "prioritise shipping route a over route b".

So I have to put it under start? Optimise? Fix? Why? Prioritise is the right word, why not just use that? Why play mind games when we have a whole dictionary to draw from?

Post reply on HN