> Some people get it in their heads that their commit history needs to be "clean". It doesn't...
If by "clean" you mean "readable" (in the literate-programming sense), then I'd be a strong advocate of that.
I would like to one day see a repo that is maintained in such a way that, if you just dump out the commits in chronological order (e.g. `git log --patch --reverse --pretty=format:"%s"`), the result is essentially a jupyter notebook that explains the system being built as it builds it.
Such a thing would require a lot of rebasing, of course.
I think this repo is clearly the result of "development in private", but I don't think the commit messages here were "cleaned up." I think this is just this person's way of using git in a single-user context — they just want to incrementally save WIPs, so they number them. (Maybe they even use an editor plugin that does this for them on save, or through a keyboard-shortcut.)
That being said, I do sometimes also see this in the cases of private repos that were so messy and fraught, with long-lived now unmergeable feature branches, that the best way to integrate everything was to just convert each long-lived branch into a set of .patch files; manually prune and edit those .patch files in a text editor; and then `git am` each patchset into a synthetic commit. Those commits don't really have coherent purposes — they're just incremental steps of a single long integration — so you may as well just number them. (Usually, though, people rebase-squash these all once they're done.)
Which, if the case, is even more awful. Now to understand the change history, I need to consult/cross-reference some documentation page that might 404 in the future. Additionally, the releases have many un-related changes grouped together (as one would expect for a release, not a commit).
Lately I've become fond of the squash-merge. All development is in a branch, and to merge you open a Pull Request (or equivalent on whatever platform you use). The PR gets squashed into one commit that references the original PR, which retains all of the commit history and discussion/review comments. Best of all worlds in my opinion, and frees developers to commit freely without consequence or care.
Just to comment on your last paragraph - I don't really understand people's obsession with having squashed commits on main. I may not have a local copy of the branch that was merged months ago, so I can't get the un-squashed history without jumping through hoops. It also makes tools like git-bisect much less useful.
With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged into mainline wholesale, without any further squashing.
Each commit has the ticket id in the commit message, so you can find all related changes easily if ever needed. This gives us history that's both granular enough to be useful, and meaningful.
(Granted, if your team is disciplined enough to only have very small and granular PRs that only deliver a small logical unit of change at a time, the distinction between approaches becomes moot... but in my experience most PRs tend to be a little bigger that that, and contain at least a couple of related but distinct sets of changes)
And yeah, the commit history in this project is just hilarious.
> With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged ...
A lack of this simple discipline is what causes people to push for squashing. If you squash every PR then your commits may be too coarse, but you don't end up with random "fix tests" commits everywhere. If it's not part of your company culture to do the cleanup then it's harder to get that rolling than to just impose a repo rule that only squash merges are allowed in.
>Some people get it in their heads that their commit history needs to be "clean". It doesn't...
I do not care about git commit history at all. Do not squash. Don't do anything other than commit, push, and merge PRs. I don't delete old branches, I don't do anything beyond the basics. I don't even use rebase. It has never bit me in the ass at all in all the years I've been running this team. The less I have to do with git, the better.
Exactly. We have a beautiful tool that can maintain an unbroken historical record without being a burden... and then we use it to rewrite history? Nooooo!!
I have surely seen a handful of cases where squashing and rebasing to keep history clean would make my work way easier. But the squashing and rebasing would waste way more time than those would gain.
I guess if you are managing a popular public repository, at some point the trade-off inverts.
I guess it depends on the developers and how they choose to commit. On my team we don't commit unless we're ready to push, so we aren't creating 100s of commits for every feature or bug fix. Some developers seem to think they need to commit every 2 seconds for every tiny little change. That's just seems like a waste of time to me, and it also creates the need to squash and do more stuff with git. Anything that distracts me from writing software and putting work into the code is a distraction, and git is a distraction. I don't really want to deal with git as often or as much as some developers seem to use it constantly to commit everything...
Dunno for me it's great to commit if I just made substantial work but it's not ready yet. It's assuring that my work won't be accidentally lost if I mess up. Especially it's great to commit at the end of the day or if I just wrote tests which all pass. Stuff works, I can move on, and forget about it. Next day when I write more code, and something breaks (but worked yesterday) I can easily see the diff between yesterday and today and see what changed and where I'm currently at. Commit messages remind me of what I did, step by step. Then I push to the dev environment and if QA finds bugs, I commit new changes which fix the bugs. It's also great for the reviewer - they only have to look at the single bugfix commit, the rest of the code is fine (already reviewed). I don't find a use for squashing, modern tools allow to see several commits as one diff.
> This has the appearance of "developed in private, cleansed, thrown over the wall" sort of thing.
To be honest, I do this with personal projects, and by "this" I mean I finish the project, try to polish it and "cleanse" it as much as possible, and then git commit add with message "Initial commit", and after that of course I have proper commits for bug fixes, feature additions, etc.
Commit history has to be clean just as much as code has to be clean. That is to say, it doesn't - but it's far nicer working with clean code than tangled uncommented messes.
Most of the commit messages in my personal projects say “Temp” and yet to see any issues with that. I have some repos where I maintain commit messages (by inertia) and it always bugs me as an utterly useless routine.
In the rare case when I have to investigate history, there are actual code changes and all the tools to navigate them. There’s no “read through the log to find a change” in my workflow, just like there’s no “read through code to find an identifier”.
It doesn’t mean that this works for all projects and workflows. People report their day saved by a commit message. But that blanket belief in sacred commit messages is just that. It’s not unusual to see a 1-person repo to contain synthetic messages cause under no peer pressure people act like it’s natural to them.
