I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.
How to write a Git commit message (2014)
31–40 of 185 posts
Re: How to write a Git commit message (2014)
#32I 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
Why? Wouldnt the commit history contain only the one squashed commit and its legible message?
Re: How to write a Git commit message (2014)
#33Earlier 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…
Yep, `--allow-empty` is my preferred solution. It's unfortunately not up to me how other people choose to do this
Re: How to write a Git commit message (2014)
#34Earlier 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!" 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…
It would also help if people were better about keeping a clean commit history for PRs. Ideally, a new commit should only get pushed to a branch per change relevant for reviewers. If the CI is causing the error, people should work on a temporary branch and resolve it there first before cherry picking things over into the PR branch (after rebasing the intermediate commits on the temp branch).
Rebasing is a really nice tool, though I think the UI is really lacking. A simple GUI for interactive rebasing would help a lot. Most clients I've used (which isn't a ton since I generally prefer the CLI) don't even have an option for rebasing at all.
Re: How to write a Git commit message (2014)
#35I 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 well enough if (and only if) your company has a culture of small, atomic PRs.
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 got a long branch history that adds essentially no value (i.e. "Tried this thing/Didn't work reverting/Tried this other thing/Still no dice/Switching workstations").
An arbitrarily large number of file changes can be packed into a single commit, sometimes for review purposes it makes sense to purposefully isolate different groups of changes in a manner that doesn't mesh with how the dev work was actually done - sometimes I just don't want to have an ugly commit history. I'm allowed to be OCD about my work and sweep the commit where I added print __LINE_NUM__ between each LOC to track down a bug one time that I was too lazy to use gdb under the rug.
Re: How to write a Git commit message (2014)
#36This has been my commit bible for years. I feel like it has been battle tested and has made my life easier.
Re: How to write a Git commit message (2014)
#37I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.
Writing a good commit message within those constraints is kind of like writing a haiku. It's kind of entertaining sometimes, though I think it should be a suggestion rather than a rule.
Re: How to write a Git commit message (2014)
#38Earlier 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!" 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…
> github's naive view of history where it shows things in a bafflingly obtuse linear
This hits home, it pretty much describes how I visualize logs in my head (compared to the visualizations I see that are more 2-D, branching off and merging together, etc.). I have a hard time working with some of the more advanced features because of this, and it'll probably always be an uphill battle to shift my thinking from linear to not-so-linear ...
Re: How to write a Git commit message (2014)
#39I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.
I know the articles calls it a rule, but really it's more a guideline. It's so that `git log --oneline` and `git shortlog` produce succinct output. It's also the email subject when using `git format-patch`. With all of these, the idea is to have a quick-to-read summary of the commit. That's all, really.
Re: How to write a Git commit message (2014)
#40Earlier quoted context omitted.
This works well enough if (and only if) your company has a culture of small, atomic PRs.
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.