Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Write a Git Commit Message (2014)

chris.beams.io

Post reply on HN
Print view View original

101–110 of 121 posts

Re: How to Write a Git Commit Message (2014)

#101

Post by CydeWeys »

phailhaus wrote: post #98
CydeWeys wrote: post #54

Earlier quoted context omitted.

Private commits aren't immutable at all. You can change anything about them up until you push them to a remote repository that other people are syncing from. I routinely squash a bunch of private commits together before issuing a public PR, for example.

Commits are immutable; when you squash commits you're replacing them with new ones and rewriting the history. And since there is no difference between your local repository and the remote one, the reason why you wouldn't squash commits on the remote repository is to be nice to your coworkers. So unlike PR's, if your coworkers criticize your commit messages it's already too late.

> And since there is no difference between your local repository and the remote one

Uhh, there's plenty of difference between your local repository and the remote one. One is local and used just by you and one is remote and used by many, for starters. Changes aren't automatically synced between them. You can rewrite commits locally to your heart's content (which I do all the time). You aren't "locked in" to anything until you've pushed it to a shared repository and someone syncs from it.

Re: How to Write a Git Commit Message (2014)

#102

Post by CydeWeys »

andrewshadura wrote: post #97
CydeWeys wrote: post #54

Earlier quoted context omitted.

Private commits aren't immutable at all. You can change anything about them up until you push them to a remote repository that other people are syncing from. I routinely squash a bunch of private commits together before issuing a public PR, for example.

No they are. You can create different commits replacing them though.

Calling commits "immutable" is thus verging into technically correct, but misleading and thus not useful territory. It's giving people the impression that commits are set in stone the moment they are made, when in fact this is far from the truth and you can go back and rewrite them, insert new commits between existing ones, squash them together, remove them entirely, etc. The only "gotcha" to watch out for is if other people have synced your changes; then you start having problems.

Re: How to Write a Git Commit Message (2014)

#103

Post by jph »

wst_ wrote: post #100
jph wrote: post #8

My team uses a git commit message convention that helps us read fast and also is parsable by toolchains. We agree on a short list of leading active verbs: 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,…

How do you enforce such commits messages? People makes mistakes, or forget stuff. But when you have a pull request, all intermediate commits are already pushed to central repository. They already are public. You can't change them anymore. Pre-commit hook?

The commit-msg hook. You can use it to validate your project state or commit message before allowing a commit to go through. The git docs demonstrate using this hook to check that your commit message is conformant to a required pattern.

Re: How to Write a Git Commit Message (2014)

#104

Post by niteshade »

bjourne wrote: post #68

It doesn't matter that much. Some things in programming mater a lot, like consistent indentation and casing. Some things doesn't, like perfectly formatted commit messages. whether the verbs in commit messages should be in imperative or present tense is just too much. I can tell you that I have been programming for a very long time. So if someone asks me "Why does it MATTER if lines are longer than 80 characters?" the…

One reason I can think of for using the imperative tense is to use commit messages to generate changelogs. AngularJS does it this way, wouldn't be surprised if there were others.

Re: How to Write a Git Commit Message (2014)

#105

Post by wst_ »

jph wrote: post #103
wst_ wrote: post #100

Earlier quoted context omitted.

How do you enforce such commits messages? People makes mistakes, or forget stuff. But when you have a pull request, all intermediate commits are already pushed to central repository. They already are public. You can't change them anymore. Pre-commit hook?

The commit-msg hook. You can use it to validate your project state or commit message before allowing a commit to go through. The git docs demonstrate using this hook to check that your commit message is conformant to a required pattern.

It's not easy to enforce local hooks. And maintaining it becomes difficult if you have a lot of small repos.

Re: How to Write a Git Commit Message (2014)

#106

Post by milesrout »

jwilk wrote: post #58
tomjen3 wrote: post #18

Earlier quoted context omitted.

From SO: >Git can take the commit message from a file using the -F or --file flags: >git commit -F message.txt So something like echo 'pmontra\n say\n this\n should be several lines' | git commit -F /dev/stdin would get around your block.

You want printf, not echo. echo is a very non-portable command. POSIX says: "if any of the operands contain a character, the results are implementation‐defined."

why would the portability of the commands I type directly into my shell matter?

Re: How to Write a Git Commit Message (2014)

#107

Post by milesrout »

scrollaway wrote: post #95
milesrout wrote: post #91

Earlier quoted context omitted.

>This text box I'm replying to you with is a plain text textbox. It word-wraps just fine. No it doesn't. In fact I had to edit a comment I made above this one about four times until I got the formatting right. It annoyingly ignored me doing this: line one line two line three and assumed I meant this: line one line two line three

You're talking about the comment output, which is html after being processed. The text box is plaintext, and it word-wraps :)

The text box and the text output are the same thing: markdown. A little tickbox that just wrapped every message I send in a 
 tag would be lovely.

Re: How to Write a Git Commit Message (2014)

#108

Post by scrollaway »

milesrout wrote: post #107
scrollaway wrote: post #95

Earlier quoted context omitted.

You're talking about the comment output, which is html after being processed. The text box is plaintext, and it word-wraps :)

The text box and the text output are the same thing: markdown. A little tickbox that just wrapped every message I send in a tag would be lovely.

You're missing my point because you don't understand the meaning I'm going for here. The comment box is not markdown, it's plaintext. This is not a rich text WYSIWYG editor.

My original point is that plenty of software does plaintext wrapping just fine and it's pretty ridiculous that consoles are stuck in this 80 character mindset.

Re: How to Write a Git Commit Message (2014)

#109

Post by andrewshadura »

CydeWeys wrote: post #102
andrewshadura wrote: post #97

Earlier quoted context omitted.

No they are. You can create different commits replacing them though.

Calling commits "immutable" is thus verging into technically correct, but misleading and thus not useful territory. It's giving people the impression that commits are set in stone the moment they are made, when in fact this is far from the truth and you can go back and rewrite them, insert new commits between existing ones, squash them together, remove them entirely, etc. The only "gotcha" to watch out for is if othe…

FTR I agree, I just pointed out a technical incorrectness.

Re: How to Write a Git Commit Message (2014)

#110

Post by jwilk »

milesrout wrote: post #106
jwilk wrote: post #58

Earlier quoted context omitted.

You want printf, not echo. echo is a very non-portable command. POSIX says: "if any of the operands contain a character, the results are implementation‐defined."

why would the portability of the commands I type directly into my shell matter?

In your shell, it doesn't matter much.

In a HN comment, it matters, because other people will read the comment and may learn bad habits.

Post reply on HN