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

161–170 of 389 posts

Re: My Favourite Git Commit

#161

Post by adamlett »

Chris2048 wrote: post #112
adamlett wrote: post #5

Earlier quoted context omitted.

I say yes. I like to keep information about the code as close to the code as possible. Issue trackers come and go, and even if you keep the same issue tracker around, how are you going to relate the change in the code to the particular issue down the road? FWIW, I also prefer READMEs to Wikis.

> 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 – utterly frustrating to deal with. They tell you nothing more than this change is somehow related to this or that bug or feature, but not how or why.

Re: My Favourite Git Commit

#162

Post by TwoHeadedBeast »

BlueTemplar wrote: post #121
TwoHeadedBeast wrote: post #118

Earlier quoted context omitted.

Virtually all use cases in my experience.

You'll have to give some specific examples...

Git is particularly poor in scenarios such as two people working on the same branch. SVN handles this with ease, but with Git it takes a lot of coordination amongst both contributors to keep things working.

Re: My Favourite Git Commit

#163

Post by Tactic »

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.

Re: My Favourite Git Commit

#164

Post by zbentley »

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?

Seems like they are. Also seems like a solid practice that far too many people ignore.

Re: My Favourite Git Commit

#165

Post by snorremd »

Chris2048 wrote: post #112
adamlett wrote: post #5

Earlier quoted context omitted.

I say yes. I like to keep information about the code as close to the code as possible. Issue trackers come and go, and even if you keep the same issue tracker around, how are you going to relate the change in the code to the particular issue down the road? FWIW, I also prefer READMEs to Wikis.

> 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 message. By all means, refer to your issue tracker in commit messages, but be aware that those references may not be valid in a few years.

Re: My Favourite Git Commit

#166

Post by beart »

vidarh wrote: post #139
thiefmeister wrote: post #76

Earlier quoted context omitted.

I have! Company promoted the guy and raised his salary because he had plan to leave the company

I know in instances like that, though, my next step would be to start working on contingency plans, as if someone has proven themselves to be indispensable, then that very fact is a risk that needs to be managed.

Like having a new guy learn the material, taught by the old guy who doesn't want anyone else knowing it!

Re: My Favourite Git Commit

#167

Post by sam0x17 »

kyberias wrote: post #103
kissgyorgy wrote: post #94

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

I think it's an appropriate response to such a blunt dismissal of an entire way of being

Re: My Favourite Git Commit

#168

Post by jordigh »

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.

> I don't want your entire life story in my commit log.

Why not? Where else do you want it? Is something forcing you to read the full commit log?

There's no length limit on commit messages and commit messages are mostly out of the way. Most VCSes have a way to only show you the first line. So if you want summaries, that's what the first line is for. If you want the full story, that's what the body is for.

Combined with annotate/blame, commit messages can be very helpful source-level documentation. Nobody has ever complained about too much documentation, and commit messages are the perfect time to document what happened because it's one of the few times where our tools actually force us to write something in order to proceed. As long as we're being forced to write something, write something good and informative.

Re: My Favourite Git Commit

#169

Post by michaelt »

deelly wrote: post #79
rimliu wrote: post #28

Earlier quoted context omitted.

It's like preventing the headache with a guillotine.

Why? Usually non-ascii characters belongs to translation, and translation usually not belongs to codebase.

Documentation stored in your repo, unit tests, and comments. If your README.md includes code bracketed with backticks, you've got non-ASCII characters in your repo.

Things like Péter Rózsa or Kg.m² or ±0.5 PPM or C11 Standard §6.3.1.3/2 all work with my toolchain. Why mangle them into ASCII when there's no need to?

Re: My Favourite Git Commit

#170

Post by powjfjti83 »

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 realize my media player project.”

Talk about sheltered suburban kids

Bet he also tossed his SNES controllers against the wall, blaming Nintendo when he ate shit in FZero

Since I have no use for MPV let’s go on a rant about writing more tools when we already have numerous open options to do the same thing

Oh right because life is relative and relative to me this is grand standing baby talk

So sick of tough guy coders. Oh rly you’re good at seeing the plot holes in text driven computer code? I mean you sit in your basement all night focusing on it so you’re a normal human that gets better at they spend time on

Meanwhile, not really contributing in a lasting way to growth of humanity with a media player or your other efforts

But of course the efforts that do live long like a general purpose performant language are the kids toys

If there’s a joke here it’s this persons life perspective

Post reply on HN