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

321–330 of 389 posts

Re: My Favourite Git Commit

#321

Post by ticmasta »

tom_mellior wrote: post #210
ShteiLoups wrote: post #130

Earlier quoted context omitted.

Yes. As is convention, commit messages should be a one line header, then and empty line an a body (if necessary). The whole thing should be width limited to 80 or 100 characters. And the subject line should complete the sentence "If this commit is applied, it will...". It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.

> And the subject line should complete the sentence "If this commit is applied, it will...". I kind of do it like this. Others use subjects that complete the sentence "This commit...", so their subjects will start with "adds", "fixes", etc. Though that adds one or two extra characters!

Like many of the pedantic things we like to argue about, I think teams/projects should choose consistency over prescription.

Re: My Favourite Git Commit

#323

Post by Myrmornis »

In an organization I've worked at we used to write good commit messages, about 9 years ago, before we started using Github. Then our good commit messages turned into good PR intros. I think Github and Gitlab etc are fantastic, but I'm a little sad that so much valuable information has been divorced from the git repository itself (and of course, the ultimate fate of those PR intros across the open source world depends on the companies hosting the repo.)

Personally, rightly or wrongly, the fact that I can't use Github/Gitlab to contribute to Django and Emacs prevents me from trying to make contributions to those projects. Similarly I find the insistence on using email to send patches, frustrating, when I know PRs (MRs) work so well. However, I guess Emacs and the linux kernel are keeping their good commit messages in their git repo and not losing them to a hosting company.

Maybe there should be tooling for automatically converting a PR intro to a commit message.

Re: My Favourite Git Commit

#324

Post by chadlavi »

jordigh wrote: post #203
mattacular wrote: post #201

Earlier quoted context omitted.

The pull request is a good place to put such a large amount of information. That would also be a good way to make sure it is seen by the broader team instead of burying it in commit history. You could make the argument that then it would not be part of the git history and therefore could be lost if you change hosts.

I will make that argument. The hosting is ephemeral, the commit message is eternal. Plus, what if you want to know what happened and you're simply offline? Let's not unnecessarily break the D in DVCS.

This is a really convincing argument. I was with the parent commenter until I read this; I was like, this is totally PR stuff! But hadn't considered offline situations, or host switches. Thanks op!

Re: My Favourite Git Commit

#325

Post by wh-uws »

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…

If someone made enforcing this convention a git hook I would use it in a heartbeat.

I.e. Love using husky to enforce code conventions through linters...

Only issue is it would be hard to completely enforce in code and obviously require some review but still nice

Re: My Favourite Git Commit

#326

Post by groestl »

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…

I like the convention, but I challenge the idea that optimization can be just a refactoring.

Re: My Favourite Git Commit

#327

Post by pololee »

> I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. 1000000% agree!

One of my co-workers in my previous job, I miss reading his PR and git message. It's such a joy reading his PR. I still remember reading his PR on introducing Babel to our big, old Rails 4 app before webpacker, Ruby Babel Transpiler came to life. It's like taking a journey with him. You can see his smile, struggle, surprise and all the emotional moments in his commits. He put his findings, why he made this decision, and where he found this solution in the commit msg. I learned a lot just by reading his PR. I think reading a well organized PR, clean git commits and descriptive commit messages (even the code review comments are very useful) is one of the best ways to learn in work, especially for new hires.

Re: My Favourite Git Commit

#328

Post by blaisio »

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"

Re: My Favourite Git Commit

#329

Post by rustbear »

derefr wrote: post #217

I’m torn about whether I’d like to see this kind of information in a commit message, vs. Something more like: “Remove parser-unsupported character. Closes #340295.” ...where ticket 340295 (wherever, not necessarily Github Issues) goes into more detail about the cause, investigation, and resolution process, as a history of the evolution of said process across a conversation.

The problem with this approach is when the team changes its ticketing system or the codebase goes to a different team (that has a different ticketing system), meaning all that context is lost. Happens all the time.

Re: My Favourite Git Commit

#330

Post by krick »

mikehollinger wrote: post #125
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...

My favorite (in terms of dark humor, if we’re honest) is YOLO, one of the more interesting deep learning object detectors. [1] It is the exact opposite of yours in every way. The code is brilliant however. Even the papers are snarky. [2] [1] https://github.com/pjreddie/darknet/commits/master [2] https://arxiv.org/pdf/1804.02767.pdf

Yeah, it's fun, but, seriously, git log is messy AF. I wouldn't appreciate it a bit, if somebody would do that to a project I'm involved in.

What's funny, though, the paper (written in a pretty much the same "fuck you" manner) is much more readable and informative than the average. Which says a lot about science papers out there.

Post reply on HN