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 Favourite Git Commit
101–110 of 389 posts
Re: My Favourite Git Commit
#102I do feel like Git commit descriptions are severely under-utilised for sure, but I believe there is a reason for that which until fixed, will prevent rich and contentful commit descriptions for flourishing. In the article order: the screenshot is from a commit detail page. How often do you land on this page? You need to specifically click through. If you are in a commit list, the only thing that sets title-only commi…
If only important/tricky commits have long messages it's fine. Most IDEs will show you the full text if you hover over the line, so when working on something it's easy enough to check them. I'm huge fan of the timemachine-like "Show Git History for Selection" view that IntelliJ has, so usually there's no reason to go to a Github/Gitlab commit page.
Re: My Favourite Git Commit
#103> I don't want your entire life story in my commit log. Then I never want to work with you ever (or any code base you ever touched) because of your laziness and lack of experience working with huge code bases where long commit messages are life-saving. Also you don't care about your colleagues and long-term maintainability. Debugging bugs for months and weeks because of lack of proper commit messages is the most frus…
>> I don't want your entire life story in my commit log.
>Then I never want to work with you ever (or any code base you ever touched) because of your laziness...
What an incredibly aggressive response.
Re: My Favourite Git Commit
#104Earlier 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…
> I don't want go look at an external issue tracker Related question: are there projects that use git itself as issue tracker?
I can imagine that working to a degree: Make a fork of a commit at an issue, then merge that fork back in with master at point of fix. Bit of a mess in the tree though.
Re: My Favourite Git Commit
#105> I don't want your entire life story in my commit log. Then I never want to work with you ever (or any code base you ever touched) because of your laziness and lack of experience working with huge code bases where long commit messages are life-saving. Also you don't care about your colleagues and long-term maintainability. Debugging bugs for months and weeks because of lack of proper commit messages is the most frus…
>> I don't want your entire life story in my commit log. >Then I never want to work with you ever (or any code base you ever touched) because of your laziness... What an incredibly aggressive response.
The comment it responded to wasn't exactly friendly either.
Re: My Favourite Git Commit
#106> I don't want your entire life story in my commit log. Then I never want to work with you ever (or any code base you ever touched) because of your laziness and lack of experience working with huge code bases where long commit messages are life-saving. Also you don't care about your colleagues and long-term maintainability. Debugging bugs for months and weeks because of lack of proper commit messages is the most frus…
>> I don't want your entire life story in my commit log. >Then I never want to work with you ever (or any code base you ever touched) because of your laziness... What an incredibly aggressive response.
Yes, because developers who want to spare minutes of work for others to spare DAYS OR maybe even WEEKS of work deserve shaming. It's very frustrating.
Re: My Favourite Git Commit
#107I 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...
Final paragraph:
> All in all, I believe this proves that software developers as a whole and as a culture produce worse results than drug addicted butt fucked monkeys randomly hacking on typewriters while inhaling the fumes of a radioactive dumpster fire fueled by chinese platsic toys for children and Elton John/Justin Bieber crossover CDs for all eternity.
I also nominate this commit.
Re: My Favourite Git Commit
#108I 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 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
#109Earlier 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…
> I don't want go look at an external issue tracker Related question: are there projects that use git itself as issue tracker?
Re: My Favourite Git Commit
#110Earlier 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…
Write a regression test (including its documentation) instead of just documenting the issue in human interpreted language, immutably. Your future maintainer will thank you for not having to dig through repository history.
It goes without saying that commits should include tests that cover the change, where possible.
> immutably
That's what makes this modus operandi so powerful IMO - comments in code may go unmaintained, tests may start failing for other reasons, issue trackers come and go, developers leave the company, documentation rots.
The commit message is (unless you have a bad actor) immutably linked to the original change, and that's exactly why you should be thorough in expressing its reason for being. I can git checkout the point in time (perhaps having bisected) and have the information to allow me to reproduce the issue.