Live data from Hacker News

My Favourite Git Commit

fatbusinessman.com

311–320 of 389 posts

Re: My Favourite Git Commit

#311

Earlier quoted context omitted.

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.

Opinions are relative. My over the topness is on purpose. The tone of the commit message resonates with exactly the same tone as my post (to me). The commit comment is filled with judgmental, caustic language toward the efforts of others. Yet my opinions about the persons view of “how to design language” are over the top. So you get my point entirely it seems. Are those people less passionate and deserving of such a…

Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...

Re: My Favourite Git Commit

#312

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…

We detached this subthread from https://news.ycombinator.com/item?id=21290517.

Re: My Favourite Git Commit

#313

Earlier quoted context omitted.

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

The real WTF is: Apparently there is a place called "Unalaska" in Alaska !

My understanding is that the in the local language "Alaska" means "Peninsula," and "Unalaska" means "Near the peninsula."

Re: My Favourite Git Commit

#314

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

You've repeatedly crossed into personal attack on HN recently. That's not cool. I've banned this account until we get some indication that you've read https://news.ycombinator.com/newsguidelines.html and sincerely want to use HN in its intended spirit. That spirit is intellectual curiosity and kind, thoughtful conversation.

Comments like this one, and https://news.ycombinator.com/item?id=21276666,

and https://news.ycombinator.com/item?id=21204403,

and https://news.ycombinator.com/item?id=21149400,

and https://news.ycombinator.com/item?id=21123836,

are not ok here. It's a pity, because you've also posted quite good comments. But they are not worth the cost of the worst ones.

We detached this subthread from https://news.ycombinator.com/item?id=21290076 and marked it off-topic.

Re: My Favourite Git Commit

#316

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

[deleted]

Re: My Favourite Git Commit

#317

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…

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

I think this is totally OK, just as long as you squash those all down before someone has to merge your PR.

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

Because it's hard to make sense of all those little commits later, so why keep them around? They're just noise with a very limited future value, and I don't want to have to sift through them in the future. It's basically impossible to clean up those kinds of messes once they get established in master, but it's very easy to contain them at pull request time.

Re: My Favourite Git Commit

#318
post #299

Earlier quoted context omitted.

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"

[deleted]

Re: My Favourite Git Commit

#319
post #200

Earlier quoted context omitted.

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.

In my workflow, that would be in a feature branch, and exploratory branches can certainly break, but before I made a PR I would rebase my changes such that none of the commits broke the build.

It's also a different situation. The original one is "I've made a test that shows a problem." Your example is a surprise "I don't know whether this will pass my cloud-based tests." I would edit my branch if I had a surprise failure, since my initial code clearly wasn't correct.

Re: My Favourite Git Commit

#320

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…

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.

Is the "subject line" the same as the "header" in this schema?
Post reply on HN