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

71–80 of 389 posts

Re: My Favourite Git Commit

#71

Post by Cthulhu_ »

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.

For critical applications, I for one would like to know the story behind a commit, preferably in the commit itself and not a reference to an external system like idk, Jira.

My favorite examples of commit messages are the Linux kernel, where you can tell that they're being specifically crafted instead of just used as a work log to be ignored. This means that ten years down the line, people can still see when a change was made and why, who was involved, who signed off on it, etc. Have a look at the commits at https://github.com/torvalds/linux/commits/master

Re: My Favourite Git Commit

#72

Post by messe »

govg wrote: post #62
withinboredom wrote: post #57

One of my favorite pranks is to put control characters in the commit message (like the bell) and then you get an auditory notification anytime anyone nearby opens your commit messages.

Does this actually work on modern editors / browsers?

Only in the terminal. That said, the first thing I put in my .xsession is `xset -b` to disable the audible bell.

Re: My Favourite Git Commit

#73

Post by UK-Al05 »

codegladiator wrote: post #25
chris_wot wrote: post #16

Earlier quoted context omitted.

Why not put it in both?

Commit messages should be short and to the point. I don't want to read a story to understand what this commit did.

Who says this?

I follow the linux kernel guidelines, which have large descriptions in commits. After all these guys wrote git.

Here's linus's take https://gist.github.com/matthewhudson/1475276

Re: My Favourite Git Commit

#74

Post by pdpi »

codegladiator wrote: post #25
chris_wot wrote: post #16

Earlier quoted context omitted.

Why not put it in both?

Commit messages should be short and to the point. I don't want to read a story to understand what this commit did.

“Convert utf-8 to us-ascii to fix error”. Says right there in the commit title, short and to the point.

Absent some automated summarising functionality that produces just the right level of detail for you personally, a concise title and a very detailed commit message that you can skim through to find relevant bits is an eminently reasonable compromise.

Re: My Favourite Git Commit

#75

Post by BlueTemplar »

hleszek wrote: post #10

To avoid those kind of issues, non-ascii characters are forbidden in our code base. They are automatically verified in a pre-commit git hook.

This issue would never have happened using modern software. And if your text (including source code) still isn't in UTF-8, you're doing it wrong.

(I guess unless you're using some specific, very performance-conscious system that has to use 7/8-bit characters and is never going to connect to the Internet anyway.)

Re: My Favourite Git Commit

#76

Post by thiefmeister »

throw0101a wrote: post #58
dmortin wrote: post #51

Earlier quoted context omitted.

> 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 Some people do it for job safety. The logic is if you don't document things and the knowledge is only in your head then you are more valuable, they can't get rid of you easily. If you document everything meticulously, then you are easier to replace.

> Some people do it for job safety. The logic is ... Has anyone actually seen this logic work out well for the person that invokes it? Generally the type of person that uses it is one that you probably don't want on your team.

I have!

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

Re: My Favourite Git Commit

#77

Post by m_sahaf »

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.

On the other end of the spectrum you get ImageMagick useless commit messages[0].

That extreme aside, I'd rather have commit messages that delve into the why-and-how the commit alters the behavior to the better rather than cryptic message as 'Replace invalid ASCII char'. Now we have documented reasoning and thought process that can aid future debugging. They can also be beneficial for new devs hacking on the project, or students learning how to implement and improve systems.

Personally, I enjoy reading these. The Go commits often have commit messages like these, and they are shared on HN often for a reason. They're learning material. They can't go on a wiki because they're tied to particular set of changes in a particular point in history. They also can't be comments on the code because they're tied to particular lines in different files, and code comments can only cover a set of consecutive lines in one file.

One recent example I could find is this[1]. Yeah, it fixes ^Z, but why didn't the old approach work? Why did it work for some time then didn't? How did it change? Why is this commit optimal, if it is? All of this along with scenarios to reproduce the issue.

Give me your life story anytime over cryptic message.

[0] https://github.com/ImageMagick/ImageMagick/commits/master

[1] https://github.com/golang/go/commit/610d522189ed3fcf0d298609...

Re: My Favourite Git Commit

#78

Post by ryukafalz »

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…

Where they're really valuable, IMO, is when you're tracking down when/why a change was made with `git blame`. When you're looking for the reasoning behind a change, it's extremely helpful if there's a detailed commit message going along with it.

Re: My Favourite Git Commit

#79

Post by deelly »

rimliu wrote: post #28
hleszek wrote: post #10

To avoid those kind of issues, non-ascii characters are forbidden in our code base. They are automatically verified in a pre-commit git hook.

It's like preventing the headache with a guillotine.

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

Re: My Favourite Git Commit

#80

Post by mlang23 »

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…

Talented coworkers dont need documentation very often... If someone cant figure out how to compile something, its likely they are missing knowledge about the language in general...
Post reply on HN