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

271–280 of 389 posts

Re: My Favourite Git Commit

#271

Post by claytonjy »

SamBam wrote: post #200
0zymandiass wrote: post #88

Earlier quoted context omitted.

To me, at least, the issue with that commit message is the signal-to-noise ratio. There is a lot of exposition for each piece of information. I prefer a more declarative commit message. However, from the writing, I suspect this is just due to the committer not being a native English speaker. e.g. the first paragraph doesn't lose any important information trimming it down to: "After adding a test matching the contents…

Hmmm, I've always believed that no commit should break a build, even if you're committing the fix right after. Otherwise you're going to cause problems for `git bisect` or other practices of going through the history to find where a problem may have started. Do other people commit breaking tests and then fixes?

I do this, but not in a way then end up on master. It's a driving force behind my preference for squash-and-rebase merge patterns.

A good bugfix PR is often two commits then: one with a test to catch the breakage, another to fix it so the tests pass. Reviewers can see the failing-then-passing CI job logs, so if they agree your test catches the bug, they have additional CI-automated validation your fix worked.

Then as long as you squash when completing the merge, you get the best of both worlds.

Re: My Favourite Git Commit

#272

Post by adamlett »

Chris2048 wrote: post #225
adamlett wrote: post #161

Earlier quoted context omitted.

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…

* 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?*

… Or, and hear me out, how about not worrying about that, and just use your VCS to accomplish something it’s imminently well suited for?

Also, how do you propose I solve the issue of the issue tracking service maybe going out of business or that of a more compelling product coming along?

To me, the primary purpose of an issue tracker is to collaborate on and track work in progress, and that’s what I use them for. I don’t find that they are particularly valuable as historical records of the source code.

Re: My Favourite Git Commit

#273

Post by pricci »

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 also use something like this. A variation of Angular's commit convention[1]. There are tools like commitizen[2] that can help new adopters to build commit messages.

[1]: https://gist.github.com/stephenparish/9941e89d80e2bc58a153

[2]: https://github.com/commitizen/cz-cli

Re: My Favourite Git Commit

#274

Post by com2kid »

konsnos wrote: post #44
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.

This is true when you can reference the commit to an issue. Then, seeing the simple commit message you can select if you want to dig up what happened by reading up the comments at the issue. On the other hand it really gets into my nerves when people don't use the task/issue/whatever manager system appropriately. Recently, I lost a couple of days trying to figure out how to compile a c++ framework because the other g…

> Recently, I lost a couple of days trying to figure out how to compile a c++ framework because the other guy didn't document his pipeline.

This is assuming documenting the pipeline would have been helping! You may have spent a few days instead figuring out why your seemingly identical setup couldn't reproduce the build...

Not that I'm bitter about build systems or anything.

Re: My Favourite Git Commit

#275

Post by jstarfish »

SamBam wrote: post #245
camochameleon wrote: post #215

Earlier quoted context omitted.

On the topic of cats vs automation, I'd recommend reading this post [1] describing the arms race created by the writer's cat attempting to break into an automated feeding machine. HN discussion here [2] [1] http://quinndunki.com/blondihacks/?p=3023 [2] https://news.ycombinator.com/item?id=13230904

We had an automated feeder with two chambers, each held down by a rotating, ticking timer switch. You rotate the switch to, say, 12 hours in the future, and 12 hours later the slot lines up and the lid pops over. After many months, my cat learned to stand on top of the lid and use both paws to rotate the switch forward until the lid popped open. This blew my mind. The switch was separated from the lid. I could imagin…

Never underestimate captive animals (or humans). They have nothing but time to observe your patterns of behavior and learn from them...

Re: My Favourite Git Commit

#276

Post by ashes-of-sol »

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.

For some, the word has indeed been given meaning, and was used to bully and demean them. There are plenty of other words to use, so that they don't have to hear it

Re: My Favourite Git Commit

#277

Post by cryptonector »

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 needs to be REQUIRED READING at the Open Group and the ISO C standards committees.

I'll quibble just a bit and say that:

  a) the C locale should be a UTF-8 locale...
     that tolerates invalid sequences (because
     the C locale historically is a just-use-8
     locale),
  
  b) even with new functions that take a locale
     handle, we need functions that use a global
     one, however that global one should be set
     once and NEVER changed in the life of the
     process, and it should be set either before
     main() starts, or before main() does anything
     that needs a locale, or starts any threads.

Re: My Favourite Git Commit

#278

Post by monsieurbanana »

SamBam wrote: post #200
0zymandiass wrote: post #88

Earlier quoted context omitted.

To me, at least, the issue with that commit message is the signal-to-noise ratio. There is a lot of exposition for each piece of information. I prefer a more declarative commit message. However, from the writing, I suspect this is just due to the committer not being a native English speaker. e.g. the first paragraph doesn't lose any important information trimming it down to: "After adding a test matching the contents…

Hmmm, I've always believed that no commit should break a build, even if you're committing the fix right after. Otherwise you're going to cause problems for `git bisect` or other practices of going through the history to find where a problem may have started. Do other people commit breaking tests and then fixes?

I might be missing something basic here. Isn't the "no commit should break a build" impossible to enforce on a codebase where you need to push a commit to run the tests?

Something where you can't test locally, like when testing on multiple architectures or when the tests just take too long for a laptop.

Re: My Favourite Git Commit

#279

Post by btilly »

hermitdev wrote: post #265
btilly wrote: post #243

Earlier quoted context omitted.

Oh. Locales. The remembered pain. Save a file in Notepad. Open in vi. See that it is different. Find data in the database, no clue the weird characters were originally supposed to be. And so on and so forth. I once wrote a reasonable program and sent it as a bug report to the maintainer of the Perl module DBD::File. He sent it as a bug report to BerkeleyDB. They said they never thought about it but yes, that would be…

> Oh. Locales. The remembered pain. More like the ongoing pain. I had to write the following just this year because SQL Server still defaults to using CP 1252 for text. The culprit? One of those damned stylized quotes that Office loves to insert for you. The code: def _wrap_str(value: str): try: return SqlVarChar( value.encode("cp1252") ) except UnicodeEncodeError: logging.getLogger("bulk copy").exception(f"value cau…

I would call that Windows pain at this point, not locales.

In the Linux/Postgres world, everything is UTF-8. Which is the default for all internet protocols. Do that and the pain is gone.

Of course Windows doesn't do that...

Re: My Favourite Git Commit

#280

Post by ilitirit »

Tactic wrote: post #163
ilitirit wrote: post #131

This really just depends on your team/company/culture. Lengthy commit messages are not really required if you have associated tickets in a bug-tracking or project-management system. More often than not, you'll just be duplicating info.

This is true until the company changes the bug-tacking and project-management software without properly porting over everything because they use different identifiers. I tend to put a link to the external system with a very brief explanation, allowing someone to quickly assess the what and why with the ability to dig elsewhere for more detail.

You could say the same for improperly porting commit messages when switching version control systems.
Post reply on HN