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

41–50 of 185 posts

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

#41

Post by ninkendo »

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.

Careful here… if is not in the ancestry of HEAD, resetting to it may have the effect of undoing any changes that have happened on the branch that aren’t in yours.

To be safe, you can do:

    git reset $(git merge-base  HEAD)
Which puts HEAD at the last commit in common between your branch and … which, if target is already a parent/ancestor of your commit, is the same thing. But if target has had changed since you branched from it, this prevents you from undoing any recent commits.

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

#42

Post by slaymaker1907 »

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.

I've tried with the idea of an autocommit chron job or something which just uses timestamps and periodically rebases things to avoid tons of commits.

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

#43

Post by mwt »

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.

Honest question, do you really expect your history to be meaningful long-term? Or are you simply taking the approach that the commit message is meaningless and a developer instead use GitHub search to find a PR relevant to a change they're investigating.

For example, I pulled up one of your projects and the history (https://github.com/transitive-bullshit/kwote/commits/main) is less than meaningless, compared to i.e. using emojis as a shorthand (https://github.com/tiangolo/fastapi/commits/master)

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

#44

Post by mdoms »

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…

I do 99% of my coding at work. At work we have Gitlab, Confluence and Jira and these all already contains mountains of context for all of our work. Pretending this context doesn't exist and storing it all in a Git repository isn't helpful.

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

#46

Post by munk-a »

mwt wrote: post #40
munk-a wrote: post #35

Earlier quoted context omitted.

Not really, I recently merged in a two commit branch where one commit was me changing all the vendor configuration for the framework we were using to a new version and the other was all the changes needed to support the change. That PR affected thousands of files in total but the need to frequently rebase the branch to avoid killer merge conflicts encouraged a low commit count. rebase -i can be your friend if you've…

Yeah, I mean my comment more as a criticism of universally squash-merging as a policy since, not so much an endorsement of it in general. I run into cases like you describe pretty often, and I doubt I'm alone. Switching to squash-merging has some benefits but it's also brought out a fresh form of hell when too many changes are happening in too many branches at once.

Oh absolutely - we have a pretty modest sized company and we do tend to "always create merge commit" because it makes some of our deployment tooling easier but otherwise git preferences are left up to the dev and the particulars of the situation.

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

#47

Post by js2 »

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…

There's a few reasons why this is a lossy workflow compared to commits with proper messages that are later merged, not squashed into one.

1. The PR itself becomes a single giant commit. To adequately explain the diff in a single message would require writing an essay instead of a few paragraphs. It is also now hard to tell which part of the PR message is associated with which part of the massive diff.

2. If something breaks, you can't dissect into which part of the diff caused the problem.

3. It's harder to document your work as you go. I may be working on a PR for days or weeks. Commits give me an opportunity to document each part of my change _at the time I make the change_. It's a chance for me to record how and why at the time it's fresh in my head. If I wait to do this until the PR is ready, I likely will have forgotten some bit of context I wanted to record about the commit.

4. It encourages sloppy commits, making a large PR harder to review. Ideally, I should be able to review a large PR by looking through each commit.

If your reply to all this is to say you should just submit smaller and more frequent PRs, fine, but then why ever have PRs that consist of more than one commit?

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

#48

Post by lelandbatey »

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

I do 99% of my coding at work. At work we have Gitlab, Confluence and Jira and these all already contains mountains of context for all of our work. Pretending this context doesn't exist and storing it all in a Git repository isn't helpful.

I also do my coding at work, with Gitlab/Github, Confluence and Jira. And yet, due to various leadership decisions and technical migrations over the years, we have lost huge piles of records due to migrating work trackers, document stores, and VCS hosts (e.g. Unknown -> Jira -> Pivotal Tracker -> Jira). Due to these crappy migrations, we don't have old merge requests, old wiki documents, and even some old repositories. Sure, it's possible to find those in old archives sitting in an S3 bucket if I were to take a couple days, but they're not 'at my fingertips'.

What is at my fingertips though? All the git commits of every repository that we still have. Which means that the only thing that's actually endured has been the commits. So, on behalf of folks 5-20 years from now who'll be scrutinizing your work, please put the context into the repo directly since it's the only thing that'll stick around.

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

#49

Post by mewse »

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…

Wait, can people really not just go into their CI systems and click a “build again” button? People actually insert ‘dummy’ commits to trigger builds?

I’ve been using Concourse to run my CI for years and years and just sort of assumed that “build again” was such basic functionality that every other CI system would also have it.

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

#50

Post by swalladge »

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…

> I prefer Github's method of "git commit messages don't matter, pull requests do".

This is a bad idea unless it works well for your specific company workflows and you don't care about the future possibility of changing platforms.

Git repos are designed to be self contained, decentralised, and offline-first. If you only care about how things look on github, then the repo will have poor usability outside of github - ie. on your workstation, in your local git tools, on a repo mirror, etc.

Git commits can be a powerful tool for understanding code if the messages are useful. They are immediately accessible through local tools and can quickly add context to a block of code without breaking immersion. But that immersion is broken as soon as you hit a commit messages like "Merge pull request #123" or "fix bugs".

Post reply on HN