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

How to write a Git commit message (2014)

cbea.ms

Post reply on HN
Print view View original

21–30 of 185 posts

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

#21

Post by xorcist »

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

Command line? git normally opens your chosen editor and you are free to write away to your heart's content.

I guess you could stuff multiple -m in there and git will format it nicely, but the editor is for writing and is best used for that.

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

#22

Post by stormbrew »

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!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use.

The frustrating thing about this is that this "omg minor commits on a merged branch clutter up the log!" is entirely a UI problem created by github's naive view of history where it shows things in a bafflingly obtuse linear order instead of letting you do something like `--first-parent` like the command line client lets you do.

Git itself has more than enough tools to give you that 'squashed' view without actually squashing anything, github just has no interest in providing it to you for whatever reason.

Also yes to the sibling comment that if you want to make something happen with a commit use `--allow-empty` and not "bump number" or "add random whitespace". Please.

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

#23

Post by rubyist5eva »

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…

this works until you want to leave Github for whatever reason

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

#25

Post by stormbrew »

shagie wrote: post #19
mwt wrote: post #12

Earlier quoted context omitted.

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 wi…

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

Oh cool, I thought I was literally the only person on the planet to do this lol. I'd do it for branchpoints too except git rebase by default acts very poorly with empty commits in the edited history (deletes them). I wish this was normalized (ie. there was a flag to `git init` to add a commit message for a root commit).

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

#26

Post by rubyist5eva »

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

> It just seems like a lot to type in the command line.

I spend my entire workday day in Vim.

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

#28

Post by _virtu »

bern4444 wrote: post #10

I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like feat: support new line chart fix: update props for new line chart chore: bump dependency version What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore…

I built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifacts for npm with semantic release by spinning up a repo with some boilerplate generators I made available to the team.

Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versioning, it just gets you into the habit of thinking about the scope of the commits.

The laughable part about building that full paved road pipeline is that the biggest friction point was always when devs didn't use semantic commits. At the time when I implemented it I didn't have checks for the commit format at the pr phase. I DID have a commitizen cli option as well but that was "Too much friction". Oh boy did I get bit. As someone who was working on DX I was constantly surprised by how many questions I got about something as seemingly simple as the conventional commit format from a crowd of enginerds.

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

#29

Post by lelandfe »

rubyist5eva wrote: post #23
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…

this works until you want to leave Github for whatever reason

This happens sometimes when private repos change hands. I've worked at places where we've been given zips of git repos – commit messages reference PR and issue #'s from long distant organizations.

I've since started policing PRs whose commit messages reference things inside of our GitHub. At least provide a summary of what you're linking, for the worst case future.

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

#30

Post by sph »

transitivebs wrote: post #18

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.

But why? That's even more useless than just describing a commit in a couple words.

I'd rather see a commit saying "fix bug" when bisecting or reading a commit history than ":heart:"

Post reply on HN