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

51–60 of 389 posts

Re: My Favourite Git Commit

#51

Post by dmortin »

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

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.

Re: My Favourite Git Commit

#52

Post by laurent123456 »

messe wrote: post #46

For anybody wondering, the likely origin of the invalid character is somebody using an Apple Ireland/UK keyboard layout where # is Option-3 (AltGr-3), and non-breaking space is Option-Space (AltGr-Space).

I don't know how many times these non-breaking spaces caused problems. I think linters should prevent commits that contain non-breaking spaces. And if really one is needed, it should be encoded as ` ` or with whatever encoding is relevant.

Re: My Favourite Git Commit

#53

Post by robin_reala »

laurent123456 wrote: post #52
messe wrote: post #46

For anybody wondering, the likely origin of the invalid character is somebody using an Apple Ireland/UK keyboard layout where # is Option-3 (AltGr-3), and non-breaking space is Option-Space (AltGr-Space).

I don't know how many times these non-breaking spaces caused problems. I think linters should prevent commits that contain non-breaking spaces. And if really one is needed, it should be encoded as ` ` or with whatever encoding is relevant.

…or fix the non-Unicode compatible systems that are consuming the commit messages and breaking? If they fail with an nbsp then they’re probably also going to fail with more obviously useful non-ASCII characters.

Re: My Favourite Git Commit

#54

Post by pricechild »

Ensorceled wrote: post #42

I often review commit logs of my teams, especially while we are tracking down problems or I'm making sure the release notes capture everything. There has to be a balance between this and "WIP"; I'm imagining trying to page through the commit log to see what changed when every 1 line change has a 35 line commit associated with it.

Would `git log --oneline` not help?

Re: My Favourite Git Commit

#55

Post by 1f60c »

Ensorceled wrote: post #42

I often review commit logs of my teams, especially while we are tracking down problems or I'm making sure the release notes capture everything. There has to be a balance between this and "WIP"; I'm imagining trying to page through the commit log to see what changed when every 1 line change has a 35 line commit associated with it.

That’s the beauty of it, the first 50 characters of the first line (IIRC) will be shown as a summary, and this one summarizes 35 lines in seven words.

Re: My Favourite Git Commit

#56

Post by CGamesPlay »

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.

Still, you've left out the details that you've confirmed that there's no other instances of this in our codebase. I'm also firmly in the "all commit messages should include a test plan" camp, so you should at least say how you found the error ("bundle exec rake was run before and after").

I get you're being terse for demonstrative purposes, but even eschewing verbosity we should still convey all the pertinent information.

Re: My Favourite Git Commit

#58

Post by throw0101a »

dmortin wrote: post #51
konsnos wrote: post #44

Earlier quoted context omitted.

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

Re: My Favourite Git Commit

#60

Post by hleszek »

unfunco wrote: post #21
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 should be checked as part of the CI too, if you're doing that, some people might never install the hooks, and some people might git commit --no-verify.

Indeed but in our case it is for a private repo with only 5 developers. The hooks are installed automatically when running make.
Post reply on HN