How to write a Git commit message (2014) • Hacker News Board

Re: How to write a Git commit message (2014)

#11

Post by simonsaysso » Tue, Apr 26, 2022, 10:18 PM UTC

carlosdp wrote: post #2

I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…

For the code review step, sure, commit messages don't really matter unless your team reviews PRs commit-by-commit.

How many times do you actually change the default squashed message? If you write a series of garbage commit messages, I don't particularly trust that you'll write a very good squashed message, either. How many times do people skip updating the PR description with new information or features from comments? If your commit messages are good, the auto-squash message will be good and one will have a network dependency on GitHub to figure out what decisions went into that change.

In general I agree with your goal of a great commit log: 1 PR = 1 commit in the main branch. But I feel like GitHub is just the wrong tool to use if you want that. I used to use Gerrit, where commit messages _are_ your PR description. Sure, it makes you interact with git in some unfortunate ways, but the tradeoff is enforced commit cleanliness.

Re: How to write a Git commit message (2014)

#12

Post by mwt » Tue, Apr 26, 2022, 10:19 PM UTC

eikenberry wrote: post #6

carlosdp wrote: post #2

I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…

But the PRs aren't part of your git repository? IMO a git repository should be self contained and not require a hosted provide to give context. It lets you manage your work with superior local tooling and without a browser running. Basically I take the exact opposite approach where my PRs are always just a short summary of the commit messages and provides a place for me to put the github specific things like the "Fix…

GitHub (by default) uses the name of the PR as the merge commit message and also includes the commit message of each commit in the log. Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use.

I can't speak for everybody, but if GitHub goes down completely and I only had access to my git logs, I'd struggle to recreate ~20% of the information scattered across issues and PRs. This issue is external to merging preferences, but it's definitely not solved by squash-merges and descriptive merge messages.

Re: How to write a Git commit message (2014)

#13

Post by jrib » Tue, Apr 26, 2022, 10:21 PM UTC

themanmaran wrote: post #9

For those who write multi paragraph commit bodys, is there a tool you use to format them? Example commit on the React repo [1]. It just seems like a lot to type in the command line. [1] https://github.com/facebook/react/commit/ec52a5698e2dfea7050...

My vim will automatically wrap when I am typing a git commit message.

Should be set by default from here: https://github.com/vim/vim/blob/2f0936cb9a2eb026acac03e6a8fd...

Re: How to write a Git commit message (2014)

#14

Post by imron » Tue, Apr 26, 2022, 10:21 PM UTC

themanmaran wrote: post #9

For those who write multi paragraph commit bodys, is there a tool you use to format them? Example commit on the React repo [1]. It just seems like a lot to type in the command line. [1] https://github.com/facebook/react/commit/ec52a5698e2dfea7050...

vi :set tw=70

Re: How to write a Git commit message (2014)

#15

Post by a_t48 » Tue, Apr 26, 2022, 10:23 PM UTC

themanmaran wrote: post #9

For those who write multi paragraph commit bodys, is there a tool you use to format them? Example commit on the React repo [1]. It just seems like a lot to type in the command line. [1] https://github.com/facebook/react/commit/ec52a5698e2dfea7050...

There's a good chance this was made in Github's squash+merge dialog.

Edit: never mind, it's auto wrapped at some number

Re: How to write a Git commit message (2014)

#16

Post by knoebber » Tue, Apr 26, 2022, 10:25 PM UTC

themanmaran wrote: post #9

For those who write multi paragraph commit bodys, is there a tool you use to format them? Example commit on the React repo [1]. It just seems like a lot to type in the command line. [1] https://github.com/facebook/react/commit/ec52a5698e2dfea7050...

Emacs + magit and auto-fill-mode

Re: How to write a Git commit message (2014)

#17

Post by mwt » Tue, Apr 26, 2022, 10:25 PM UTC

This is from 2014, but I guess not much has changed since then.

Re: How to write a Git commit message (2014)

#18

Post by transitivebs » Tue, Apr 26, 2022, 10:30 PM UTC

95% of the commits on my personal open source projects use emoji commit messages. https://github.com/transitive-bullshit/commit-emoji

PRs matter a lot more than commit messages, especially if you're squashing + merging / rebasing.

Re: How to write a Git commit message (2014)

#19

Post by shagie » Tue, Apr 26, 2022, 10:31 PM UTC

mwt wrote: post #12

eikenberry wrote: post #6

Earlier quoted context omitted.

But the PRs aren't part of your git repository? IMO a git repository should be self contained and not require a hosted provide to give context. It lets you manage your work with superior local tooling and without a browser running. Basically I take the exact opposite approach where my PRs are always just a short summary of the commit messages and provides a place for me to put the github specific things like the "Fix…

GitHub (by default) uses the name of the PR as the merge commit message and also includes the commit message of each commit in the log. Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use. I can't speak for everybody, but if GitHub goes down completely and I only had access to my git logs, I'd struggle…

> Having whitespace-altering "Dummy commit to trigger CI, ugh!"

`git commit --allow-empty` may be sufficient for that "there is a new commit" trigger in many cases. If so, that may be preferable to whitespace changes as those clutter up the blame.

As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship with that initial empty commit (which I feel is preferable to an orphan branch and then a merge with unrelated histories ... though those tell slightly different stories in the log).

Re: How to write a Git commit message (2014)

#20

Post by xorcist » Tue, Apr 26, 2022, 10:34 PM UTC

elpakal wrote: post #3

carlosdp wrote: post #2

I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…

If you really want just one commit on your PR you can reset your branch to its target before you merge: git reset --soft Which will undo all commits and leave all modified files in the staging area. Then you can make one commit and force push it to replace your branch @ remote.

Or just git rebase -i like normal people.