87
Linus Torvalds on how and when to maintain a clean git history (2009)
(www.mail-archive.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 03 Aug 2025
87 points (98.9% liked)
Programming
22170 readers
20 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
Have you ever seen or created something like this?
This might explain why it might be useful to re-write history at all, and why tools like jujutsu or gerrit are interesting, in specific contexts.
In a project I'm in there are 20 commits just labeled
.. The only reason I haven't slapped them silly is they left before I started.i have a project with 10 prs and 30 commits like that, they where setting up the ci/cd and they got tired of writing meaningful commits
While exploring solutions, I use
forffto mean "follow-up/to-squash" andato mean logically separate. Sometimes other (additional) short abbreviations to know where to move, squash, and edit the changes to.Other than maybe initial development until the first stable/usable version, these never persist, though. And even then, only if it's not a collaborative project. If it is shared or collaborative, "Iterate on x" is preferable as a non-descriptive title.
I guess my commit descriptions get better with project lifetime, not worse.
I recently discovered
git commit --fixup=abcd1234: it will make a new commit with a message offixup! <message from abcd1234>. (It's the only special thing that flag does: a specially formatted commit message, which you can craft yourself if you remember the spelling of thefixup!marker.)When you later rebase,
git rebase --interactive --autosquashwill automatically mark that commit to be a fixup ofabcd1234.magit for emacs has shortcut for creating a fixup commit selecting the previous commit, I'm sure other interfaces do too.
I've found that too, which I think is because as the project matures, you're more likely to make fixes or contained features, as opposed to regular "change everything" as you explore the design in a young project.
That kind of commit quality should only really be permissible on private projects, and as a reviewer, it's arguably acceptable to reject PRs with this kind of history.
You should be writing your commits to the benefit of the code reviewer - structure them in a logical fashion to tell the story about the changes you want to get merged.
For non-trivial branches I usually soft reset to the point where all code is unstaged and uncommitted and then curate the commits to align with what the reviewer should be reading. It's not uncommon for me to have several branches containing a single "wip"-commit which I amend onto while building up the full code for the branch.