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

181–190 of 389 posts

Re: My Favourite Git Commit

#181

Post by na85 »

magashna wrote: post #157
jplayer01 wrote: post #135

Earlier quoted context omitted.

> But maybe a better question is: “What are we going to do with these detectors now that we have them?” A lot of the people doing this research are at Google and Facebook.I guess at least we know the technology is in good hands and definitely won’t be used to harvest your personal information and sell it to.... wait, you’re saying that’s exactly what it will be used for?? Oh. > Well the other people heavily funding v…

That resume is something else.

Bronies creep me way the fuck out.

Re: My Favourite Git Commit

#182

Post by schnable »

cmroanirgo wrote: post #65
leejo wrote: post #45

Earlier quoted context omitted.

> I don't want your entire life story in my commit log. I[1] want enough debug information in the commit log to be able to reproduce the issue without having to go on web hunts to understand the problem. Especially when the change appears to be trivial on the surface, because these are the ones that can turn out to be rabbit holes. I don't want to have to interrupt you to get this information because you didn't write…

≥ Especially when the change appears to be trivial on the surface Comments about the code should be in the code, where the next dev will see it. The more trivial a change, with far- reaching implications, the more important this is. Doing so has heaps of benefits: future devs understand ramifications, shows that this code has been scrutinized, makes it easier when doing refactoring /yanking, or porting code. That sai…

Agreed, but in this case, it was an encoding/whitespace change so there isn't really anywhere else to put this info.

Re: My Favourite Git Commit

#183

Post by jordigh »

I really appreciate this kind of commit message. There’s some very good ones in the Mercurial logs too:

https://www.mercurial-scm.org/repo/hg/rev/3764330f76a6

https://www.mercurial-scm.org/repo/hg/rev/93486cc46125

https://www.mercurial-scm.org/repo/hg/rev/b7a966ce89ed

https://www.mercurial-scm.org/repo/hg/rev/4a0d0616c47d (all modesty aside)

Long commit messages aren’t that atypical. Have a stroll through the logs:

https://www.mercurial-scm.org/repo/hg/log?style=gitweb

Mercurial inherited this style of commit messages from Linux email-based code review (the Mercurial originator was a kernel hacker), because in that workflow your commit messages are kind of a persuasive essay for why your commit should be accepted. I believe that writing commit messages with that kind of goal in mind, thinking “why should you take this commit?” is a good motivator for writing something good and useful.

Re: My Favourite Git Commit

#184

Post by SirensOfTitan »

powjfjti83 wrote: post #170

To an extent I find this lazy and even a humorous take is giving it attention it doesn’t deserve I can complain about anything Can this person build a language that’s still as broadly useful as C that no programmer will find issue with “Oh boy I encountered a particular odd and annoying thing. I won’t bother to offer an alternative. I’ll just complain about others efforts while ignoring they ultimately enabled me to…

This comment comes across really mean and judgmental. I didn’t read all of the original commit, but it read to me as informative and passionate with all of the frustrations solving a difficult problem comes with.

Honestly, this comment is so over the top I can’t even detect whether you’re serious or not.

Re: My Favourite Git Commit

#185

Post by lobo_tuerto »

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

I really like his licensing model, specially the META license: https://github.com/pjreddie/darknet/blob/master/LICENSE.meta

Re: My Favourite Git Commit

#186

Post by graton »

m_sahaf wrote: post #77
strictfp wrote: post #30

OR you could just write Replace invalid ASCII char. Fixes rake error 'invalid byte sequence in US-ASCII'. I don't want your entire life story in my commit log.

On the other end of the spectrum you get ImageMagick useless commit messages[0]. That extreme aside, I'd rather have commit messages that delve into the why-and-how the commit alters the behavior to the better rather than cryptic message as 'Replace invalid ASCII char'. Now we have documented reasoning and thought process that can aid future debugging. They can also be beneficial for new devs hacking on the project,…

Agreed. When at some point the website that they are pointing to changes in the future they will lose all context on why a change was made.

I believe in the "plane flying across the ocean without WiFi test" or basically anywhere without Internet access. If I am on a plane flying across the ocean without WiFi, do I have the information in the git commit to understand what happened. A git message that consists entirely of a link to a website is useless in that case.

Re: My Favourite Git Commit

#187

Post by sethammons »

I'm glad my near-exact pain has been experienced by others. I had an undefined function call of ' ' in a ruby script years ago. Finally, I turned to a hex editor at the suggestion of a colleague. The culprit was non-ascii whitespace that ruby decided should be a function declaration. Copy pasta error out of a hipchat code snippet.

Re: My Favourite Git Commit

#188

Post by twic »

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.

Re: My Favourite Git Commit

#189

Post by AlexCoventry »

JeffRosenberg wrote: post #124
strictfp wrote: post #30

OR you could just write Replace invalid ASCII char. Fixes rake error 'invalid byte sequence in US-ASCII'. I don't want your entire life story in my commit log.

Then use `git log --oneline` and you don't have to see the lengthy details, until the inevitable day when you find you need them.

How do you surface them when you need them, though? git grep?

Re: My Favourite Git Commit

#190

Post by bluedino »

cmroanirgo wrote: post #65
leejo wrote: post #45

Earlier quoted context omitted.

> I don't want your entire life story in my commit log. I[1] want enough debug information in the commit log to be able to reproduce the issue without having to go on web hunts to understand the problem. Especially when the change appears to be trivial on the surface, because these are the ones that can turn out to be rabbit holes. I don't want to have to interrupt you to get this information because you didn't write…

≥ Especially when the change appears to be trivial on the surface Comments about the code should be in the code, where the next dev will see it. The more trivial a change, with far- reaching implications, the more important this is. Doing so has heaps of benefits: future devs understand ramifications, shows that this code has been scrutinized, makes it easier when doing refactoring /yanking, or porting code. That sai…

IMO the repo is the code

However, I would have done a simpler commit and linked to an issue where I explained the problem/solution in more detail

Post reply on HN