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

111–120 of 121 posts

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

#111

Post by milesrout »

scrollaway wrote: post #108
milesrout wrote: post #107

Earlier quoted context omitted.

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.

No you're missing the point. A computer cannot wrap text reliably. It does not know how to.

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

#112

Post by phailhaus »

CydeWeys wrote: post #101
phailhaus wrote: post #98

Earlier quoted context omitted.

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…

All those differences you mentioned are not related to implementation. The remote repo is functionally identical to your local repo. You can "rewrite commits to your heart's content" on the remote repo too, there is nothing stopping you. Like I said, the only reason you don't is to be nice to your coworkers.

By the time somebody else criticizes your commit messages, you've already pushed. It's too late. All that time you had while the commit was local-only means nothing, unless you brought your coworkers over to your computer to review your commits before creating a PR. Expecting developers to get commits right the first time (before pushing) is not a sustainable solution.

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

#113

Post by phailhaus »

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…

It's not misleading at all. If you forget that commits are immutable, then you get people who think they can edit a commit message and push it up no problem.

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

#114

Post by data_hope »

ribasushi wrote: post #44
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…

> What I do miss however, is a good description of the overall change. https://github.com/ribasushi/dbix-class/commit/1cf609901 Something like that I take it? :)

excellent

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

#115

Post by data_hope »

projectileboy wrote: post #72
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…

Changing _public_ history is bad. I don't see any problem with rewriting your _personal_ history before merging it in.

Changing public history is bad, because it makes collaboration and two devs working on one branch harder.

But I do not see a problem with rewriting history on a branch, if (and only if) you kind of know that no one else is pulling the changes. Or, when merging a PR, a rewrite is okay too, if the next feature will be branched off of the trunk, too.

Also, mercurial's tooling seems to help https://www.mercurial-scm.org/wiki/ChangesetEvolution with rewritten history by making it easier to track history rewrites. Basically I think this is a path in version control systems worth exploring.

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

#116

Post by data_hope »

ibgib wrote: post #65
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.

This is what PRs are good for. Also, with my particular approach to commits, I always have at least one issue associated to a commit, and I'm always working on a particular branch associated to the issue. I pick an emoji that captures the issue/branch in a single concept, and I have that in my subject line. This is combined with my git commit template mechanism, and I like it. At a glance, I can see which commits bel…

neat

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

#117

Post by data_hope »

pm215 wrote: post #89
wst_ wrote: post #30

Earlier quoted context omitted.

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.

The main reason I request commits to be split up is for ease of code review. It's much easier to review three commits that each do one easily comprehensible small thing than one commit that does three things at once. It's also better if you find there's a bug -- you can bisect down to a commit that's fairly small where the bug should be easy to see, rather than one that's enormous and where the bug is hard to find am…

indeed, if the commits are individually reviewable it is nicer. To the contrary however often these small commits can be a bit messy. Sometimes you'll find commits that are reverted later on, or fixed up later on. I.e. for commit-level review to work well, it's great if the history was polished.

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

#118

Post by data_hope »

nothrabannosir wrote: post #46
wst_ wrote: post #30

Earlier quoted context omitted.

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.

Small, incremental commits are an asset with git blame, git bisect and git revert. I find it much easier to deal with too many small ones, rather than too few large ones. Especially if you keep the convention that master is always "merged into", i.e. "left of the merge", i.e. "parent 1".

especially with very small commits, I find small commits to be tedious and error prone (sometimes the software doesn't even build because the developer distributed two not-so-independent changes over two commits because the connection wasn't so obvious. Then you have a failed build and you don't really know if `git bisect` just beamed you into the middle of a refactoring, or whether there is an actual issue.

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

#119

Post by data_hope »

flukus wrote: post #70
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…

> As in: In the subversion days, many people commited only few times a day, sometimes not for several days. This was often the source of merge hell. Half of what makes git merges easier is the smaller commits that it encourages.

But kind of it was also the tooling. Most svn projects I worked on were trunk-based and thus integrated much tighter than git feature-branch based code. However, the times I merged subversion branches, I kind of was sure that subversion lost some changes.

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

#120

Post by data_hope »

emodendroket wrote: post #20
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 mean, aren't pull requests basically the solution to that problem?

Not if the merge commits just say `merged branch ....`.
Post reply on HN