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

291–300 of 389 posts

Re: My Favourite Git Commit

#291

Post by shrimpx »

Darkstryder wrote: post #31
tomashubelbauer wrote: post #17

I 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…

In the same vein, I wish there would be a standard workflow for putting code inside commit logs. The typical use case would be database migration scripts : IMO they are always a pain to version properly because fundamentally Git and all the other software versioning tools let you describe the "nodes" (in the graph theory sense of the word) of a codebase ("at commit A the code was in this state, at commit B it was in…

How do DB migrations relate to the source control graph?

It seems you're implying the codebase changed as a result of a script that itself is not source controlled. I can think of style commits falling in this category, like one of the children of this comment mentions, but DB migrations don't seem to be related.

Re: My Favourite Git Commit

#292

Post by schoen »

sethammons wrote: post #199
Dumblydorr wrote: post #191

Earlier quoted context omitted.

Sorry, beginner here, can you explain more simply the difference in the whitespaces? Are they just encoded differently?

There are full on character encoding introductions. I think an easy to approach one is: https://www.joelonsoftware.com/2003/10/08/the-absolute-minim... Basically, ascii is encoded as integers. '32' represents a space. However, ascii is quite limited and if you want non-US-centric characters, you need to use other character sets. For a myriad of reasons, once you go into unicode (the Universal Character Set) there are…

This explanation of where the non-breaking space came from feels really likely: https://news.ycombinator.com/item?id=21290159

Re: My Favourite Git Commit

#293

Post by hnruss »

I ran into a similar issue a few years back. There was the same non-space whitespace character spread throughout the codebase. I tracked it down to a single developer, who had no idea why that was happening. My guess was that they were copy/pasting a lot from MS Word documents, but we never found out for sure.

Re: My Favourite Git Commit

#294

Post by pault »

testplzignore wrote: post #138
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...

That reminds me of the glorious https://en.wikipedia.org/wiki/File:JIS_and_Shift-JIS_variant... .

"this is a simplified representation" :D

Re: My Favourite Git Commit

#295

Post by adwww »

gwbas1c wrote: post #224

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 comments have a habbit of getting lost during future tidy ups or refactors.

If the code is that unclear it needs a comment, refactor it into a named method, where the method name describes exactly what it's doing.

Re: My Favourite Git Commit

#296

Post by pault »

computerex wrote: post #264
john-radio wrote: post #236

Earlier quoted context omitted.

Yeah. People who use the term "retarded" that way are stupid, no matter how smart they are.

I disagree. Words are just words and we give them meaning. Being derogatory and unkind to mentally deficient folks is ethically wrong. Using that word in a different context to communicate frustrating imo is fine.

Try telling that to my boss, who has an autistic child. I held your opinion until I stuffed my foot in my mouth in a meeting. Now I don't use that word.

Re: My Favourite Git Commit

#297

Post by CydeWeys »

CivBase wrote: post #284
jordigh wrote: post #203

Earlier quoted context omitted.

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.

I never understood this philosophy. What makes Git more eternal than any other technology? Why is putting all of your data in one monolithic tool a good solution? You might change your issue tracking solution. You might change your host solution. You might change your review platform. You might also change your VCS solution. Nothing is eternal.

The commit message itself is way more eternal than GitHub ephemera. There's plenty of old codebases in git that were imported from SVN (or even older RCSes) with all commits intact. What's likely not intact is data in ancient issue trackers from decades past. git is a DVCS, so anyone can clone the repo and get all the commit information. Cloning the issues and such is not nearly so trivial, and isn't a part of the git protocol itself so there's no guarantee it's in any kind of interchangeable format.

Important information should not just be in PR comments. It should be added into the commit information itself so that it'll be maximally available going forward. A good, fully explanatory commit message is a huge asset, and those commit messages will exist for the entire lifetime of the codebase. Anything else, not so much.

Re: My Favourite Git Commit

#298

Post by oefrha »

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...

“mpv”, “sheer frustration”... I didn’t have to click the link to know it was authored by wm4.

Re: My Favourite Git Commit

#299

Post by adwww »

generaljelly wrote: post #244
CharlesColeman wrote: post #237

I really like this commit message. I've found that switching to git from more traditional version control systems requires a lot more discipline in some ways. A lot of people just commit, commit, commit lots of incremental changes with no context or story to them. I've seen pull requests with dozens of tiny commits together make up a cohesive effort, but individually are just useless. I've been really having to push…

I'm one of those people. I make lots of little commits, it gives me space to really make a mess of coding going down some rabbit hole and performing 'reset --hard' when I get too away from myself, and track what I'm doing locally. As long as each commit isn't causing a problem with CI/CD, and my pull request to master is well documented what is the value added of cleaning up commits? (Junior developer here, looking t…

Depends how you handle your PRs. If you squash and rebase within Github or similar, no problem.

But ideally interactive rebase before you push your PR and tidy up all those commits into larger topical ones.

Eg.

"DEV-1 - Write tests for widget X calculator" "DEV-1 - Implement widget X calculator" "DEV-1 - Refactor widget X factory service"

Re: My Favourite Git Commit

#300

Post by CydeWeys »

jordigh wrote: post #288
CivBase wrote: post #284

Earlier quoted context omitted.

I never understood this philosophy. What makes Git more eternal than any other technology? Why is putting all of your data in one monolithic tool a good solution? You might change your issue tracking solution. You might change your host solution. You might change your review platform. You might also change your VCS solution. Nothing is eternal.

I didn't say anything about git. I said the commit messages are eternal, and none of those changes will change the commit messages (except, perhaps, changing the VCS, but usually that will preserve commit messages too).

You'd be foolish to do a VCS migration that discards the commit messages. I've never seen it happen personally, as people tend not to be that foolish. I've worked with legacy codebases that went from CVS -> SVN -> git and all of the commit messages going back to the very beginning are intact, because why would you ever do a migration that doesn't maintain them?
Post reply on HN