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

221–230 of 389 posts

Re: My Favourite Git Commit

#221

Post by dahart »

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…

It’s a shame you see it only as complaint, the brilliant thing about the text you’re replying to is that it educates the reader as to the bigger problem, as well as being very funny. Does your complaint do either? Understanding why C locales are broken may very well contribute to the lasting growth of humanity. Did you note that Eric Raymond fully agreed?

Re: My Favourite Git Commit

#222

Post by pojzon »

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.

IMHO you should pick a right medium for some kind of messages and I dont think git commit message is the right medium in OP example. Most companies have ticketing tool to keep track of additional information like: how long did it take to solve that issue, was there any input from other people, long "marked up" message explaining what was wrong, how it was fixed and tested (markup is a lot easier to read than console log).

Using ticket number already forces you to use "the right tool" to view the message.

IMHO I would consider OP example as a bad practice and your example as a better solution.

Re: My Favourite Git Commit

#223

Post by Chris2048 »

snorremd wrote: post #165
Chris2048 wrote: post #112

Earlier quoted context omitted.

> Issue trackers come and go What do you mean? Just put an issue ID in the code and/or commit.

But then you switch out your issue tracker service from something like Jira to something else, and suddenly that ID or URL means squat. A git repository can easily be pushed to any git based service be it GitHub, GitLab, Gitea, or something else, and the commit log and commit hashes stays the same. Porting Jira issues to a different system would probably not preserve those IDs that you entered into your commit messag…

Just put the old ID in the new ticket, then search. Or put commit hashes into the ticket and search by that.

> A git repository .. and the commit log and commit hashes stays the same

If issue trackers are so transient and flaky, and VCSs are so solid, then back up your old issue tracker and put it in git. What if your issue tracker stays, but you VCS changes?

Re: My Favourite Git Commit

#224

Post by gwbas1c »

Honestly, I think better rules are:

- Whenever someone asks a question in a pull request, answer it by putting a comment in code. - Include a ticket number (for whatever ticketing system you use) in the commit

Why? I find that commit messages are black boxes. They only come out when doing a git blame, but they don't show up in my IDE. Instead, I'm more likely to run across messages like this when they're comments in code or discussions in our ticketing system.

I think if we had tighter integration among our IDE, git, and the ticketing system, detailed messages commit messages like this would be extremely useful.

Re: My Favourite Git Commit

#225

Post by Chris2048 »

adamlett wrote: post #161
Chris2048 wrote: post #112

Earlier quoted context omitted.

> Issue trackers come and go What do you mean? Just put an issue ID in the code and/or commit.

Let’s hope the SaaS issue tracker you’re currently using never goes out of business or changes the product in a way that makes it worse for you. Or, if you host your own, that it keeps you satisfied in perpetuity. Referring to the issue ID in the commit message is a fine practice in addition to writing good, comprehensive commit messages. Commit messages that consists only of an issue ID are – in my experience – utte…

> Let’s hope the SaaS issue tracker

So the solution to a unreliable issue tracking solution is dumping that responsibility on your VCS? Why not fix the concerns you have with your issue tracker?

> writing good, comprehensive commit messages. Commit messages that consists only of an issue ID

Who said anything about only including a tracker id? The issue here is the extra verbosity in the commit message. What will the tracker tickets contain that isn't in your "comprehensive" commit message?

Re: My Favourite Git Commit

#226

Post by AceJohnny2 »

magashna wrote: post #213
ISO-morphism wrote: post #211

Earlier quoted context omitted.

It's not about trying to catch attention, it's saying "I'm so good that even though this is totally unprofessional you're still going to want me"

...you're going to want me...kept away from others due to HR cringing at my presence.

You're not filtering him out of the hiring pool, he's filtering you. ;)

Re: My Favourite Git Commit

#227

Post by antsar »

Daemon404 wrote: post #151
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...

Not a commit but from the same author, so you may enjoy: https://github.com/wm4/dingleberry-os/blob/master/README.rst It does go off on a few tangents, but it's an interesting read.

> Descent 2 custom level reviews

You weren't kidding about the tangents.

Re: My Favourite Git Commit

#228

Post by mark-r »

bluedino wrote: post #190
cmroanirgo wrote: post #65

Earlier quoted context omitted.

≥ 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

This assumes your issue tracker doesn't change. I've been at my current position 8 years, and in that time we've had 3, and the first 2 are shut down.

Re: My Favourite Git Commit

#229

Post by nitely »

deividy wrote: post #136
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.

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

If you follow GP's convention then yes, and it's not a bad convention.

Re: My Favourite Git Commit

#230

Post by ska »

mark-r wrote: post #220
simias wrote: post #202

Earlier quoted context omitted.

The commit was complaining specifically about the way locales were designed, not C as a whole. While C was very successful, I don't think you could argue that C locales ever reached the same level of popularity. That being said I do agree with you that this complaining is not massively productive. Dealing with localization and non-ASCII text is notoriously difficult. Look at Java, Python 3, Windows, PHP 6 and how man…

When locales were invented, it was reasonable to assume that the locale would determine the character set. With the subsequent invention of Unicode that no longer needs to be the case, but code standards live forever.

It wasn't really that reasonable as soon as it was made global. It's exactly the kind of assumption that mostly works but has dark corners from the beginning.

Some imaginable version of locales was probably a good approach at the time, but that wasn't what got standardized.

Post reply on HN