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

31–40 of 121 posts

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

#31

Post by perfmode »

data_hope wrote: post #17
greenhouse_gas wrote: post #16

Earlier quoted context omitted.

Would be interesting if there was a way to annotate a set of commits, like "commit ???? - ????: refactored A,B, and C" so you'd get the advantage of small commits and clearer messages.

I think you can do that in a merge commit, sort of. The more I think about it, the stranger a strong aversion to rewriting commit history for clarity is. In university if I did some math / physics calculation, I would often start, and once I got somewhere, make a clean copy of the successful work to have a concise and revised version.

I am a firm believer that it's totally fine to rewrite history when working on a private branch that hasn't been pushed.

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

#33

Post by cortesoft »

perfmode wrote: post #31
data_hope wrote: post #17

Earlier quoted context omitted.

I think you can do that in a merge commit, sort of. The more I think about it, the stranger a strong aversion to rewriting commit history for clarity is. In university if I did some math / physics calculation, I would often start, and once I got somewhere, make a clean copy of the successful work to have a concise and revised version.

I am a firm believer that it's totally fine to rewrite history when working on a private branch that hasn't been pushed.

Not pushing private branches is risky though - you have no backup if something happens to your machine.

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

#34

Post by jph »

stared wrote: post #13

I really recommend angular-style commit messages: https://github.com/angular/angular.js/blob/master/CONTRIBUTI... type(scope) message e.g. feat(button) added play button Types are: - feat: A new feature - fix: A bug fix - docs: Documentation only changes - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) - refactor: A code change that neither fixes a bug no…

If you like this format, then you may want to try a similar format that uses the same purpose, plus uses words that easier to read and that make more sense to people in more cultures.

We use Add, Fix, Refactor, Reformat, Optimize, etc.

See my comment on this thread or https://github.com/joelparkerhenderson/git_commit_message

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

#36

Post by ajross »

gregmac wrote: post #19

The only one that really drives me crazy is > Wrap the body at 72 characters Why? Because the git CLI doesn't wrap properly? To borrow a quote, that seems like a 'you' problem, not a me problem. Maybe I'm just biased because these days I almost entirely interact with git through a GUI (either desktop client or web interface), and though I use the CLI occasionally (mostly for branch management, sometimes for quick com…

> Why? Because the git CLI doesn't wrap properly?

First off, the commit message is plain text (by design) and can't be "wrapped" automatically, and any tool that tried would be insane.

The reason for 72 characters is that the CLI, like lots of other presentation mechanisms (including quoting in other commits or in code), wants to indent your message for readability. And the uniform standard width for terminals has been 80 characters for like four decades now.

Must it be? I dunno. I can imagine a uniform agreement among a broad team that everyone will assume a 100 character line and all tools should enforce that. Maybe a little more, but not that much because even on a modern screen you want to have two full terminals of text readable at a time.

But that's just a number. You'd still be told by your commit message style guide (or checkpatch.pl, or whatever) to wrap your lines manually at 92 characters. Is 25% more bytes on a line really worth yelling about?

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

#37

Post by pbh101 »

gregmac wrote: post #19

The only one that really drives me crazy is > Wrap the body at 72 characters Why? Because the git CLI doesn't wrap properly? To borrow a quote, that seems like a 'you' problem, not a me problem. Maybe I'm just biased because these days I almost entirely interact with git through a GUI (either desktop client or web interface), and though I use the CLI occasionally (mostly for branch management, sometimes for quick com…

Linus Torvalds answered exactly this question [0]. Not that that means you should unblinkingly take it on authority, but the original reasoning is: the renderer doesn't alway know when a line should be wrapped. Examples: a stack trace, or long log line, or essentially any other quoted artifact that has a specific pre-determined format.

The relevant quote from the link:

  Some things should not be word-wrapped. They may be some kind of
  quoted text - long compiler error messages, oops reports, whatever.
  Things that have a certain specific format.

  The tool displaying the thing can't know. The person writing the
  commit message can. End result: you'd better do word-wrapping at
  commit time, because that's the only time you know the difference.
[0] https://github.com/torvalds/linux/pull/17#issuecomment-56611...

EDIT: small clarification and formatting

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

#38

Post by amenghra »

Useful things to have in a commit message:

- Test plan when there's no unit test (describes how to test that the patch actually works).

- Task ID (link to whatever is used to track tasks/bugs, as there's usually more context there).

- Blame rev when a patch fixes a bug, it's useful to know which commit introduced the bug.

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

#39

Post by jdiez17 »

I've found that writing commit messages by stating the problem in the subject, and an explanation of the solution in the body makes them very clear and descriptive.

For example:

    Problem: Windows build script requires edit of VS version

    Solution: Use CMD.EXE environment variable to extract
    DevStudio version number and build using it.
I got the idea from ZeroMQ's/hintjens' various repos.

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

#40

Post by relyio »

wst_ wrote: post #30
data_hope wrote: post #12

My personal, subjective impression: Commits are getting smaller and smaller nowadays. As in: In the subversion days, many people commited only few times a day, sometimes not for several days. SVN commits of course involved a sync with the server (a "push" in git lingo), and thus usually represented a much larger increment with a substantial change to the code base [X] With git, it became very common to structure chan…

I find tons of small commits a clutter and waste of time. I don't see any reason for doing so. On the contrary I can see disadvantage - reading and understanding a history later may become difficult task. After all what counts is your full chunk of work, reviewed via pull request, and merged to master. It should be treated as a whole. Has it really become so common with git? I don't see such trend around me.

Commits can serve as a supplement to documentation. When you properly commit the different logical steps that led to the current state of the code, it becomes incredibly easier for another team member to get why and how you have implemented things a certain way.
Post reply on HN