Many people are so fond of what I call commit accounting that they spend more effort on all that branches, merges and rituals than on actually getting their code to work.
One more reason to use trunk based development. Or SVN.
Moving commits from one branch to another according to a ritual. This way even simple change seems like a lot of work. The concept that machine should be one doing rituals, not humans by hand, is promptly ignored.
Sure, that's pointless busywork. Doesn't trunk-based development enshrine this, with the moving of last-minute hotfixes between the release branch & trunk?
What came to mind personally was overuse of rebasing to turn a commit log into something artificially pristine at merge time.
People do want some minimum of commit hygiene so that the repo avoids being a mystery vortex. But because distributed VCS lets you hide everything about how you actually work, people are able to get unnecessarily competitive about it.
I'm not fond of broken commits in a public timeline, and often my local commits are broken - they are snapshots of development milestones that make sense to me, but have no business being made public in the persisted timeline of a package.
I see this a lot in public timelines:
Commit A - splendid new feature
Commit B - oops, missed a semicolon
Commit C - typo
Commit D - addressing code review
Commit E - typo
That 5 commits for one new feature, and the commit I want to build from has a commit message which has nothing to do with the feature in question.
Rebasing that to a single commit takes little effort or time, and makes the timeline clear. On top of that, if you are using a code review tool which persists changes you may already have history of commit C which is probably the only other relevant commit you'd care to be able to find in the future.
It seems like this is something that should be handled by flags/tagging or some other object rather than destroying history.
Like, instead of collapsing A-E into a single commit, A should be marked as the start of project/feature/milestone/whatever Foo, and E as the completion of it, and A-E shown as a single object when viewing the history but allowing the user to drill-down to expose the internal commits.
Yes. This. The whole religion about keeping history "clean" would collapse if we had this single technical ability.
You can get some of the way there now by making use of tags or branch labels or something.
At one point, i wrote a Mercurial hook that would sit in the central repository add a tag every time someone pushed. Then, only tagged commits would be considered first-class parts of history. There are numerous problems with this, not least that none of the existing tooling is aware of this convention. The fact that Mercurial tags live in commits, which pushers then have to immediately pull, was also very awkward.
You can use branches in a similar way: do all the intermediate, historical-footnote, commits in a development branch, and merge into a master branch to publish them. Then only consider commits in the master branch to be first-class. This is roughly Git Flow, isn't it? Again, the tooling doesn't quite do everything you'd want it to around this.
Yes, you can still rebase to one commit in a Trunk model. Git-Svn and Perforce's Git-Fusion allow you to knock yourself out with DVCS (squash, local-branches) before you dcommit / push back to the canonical repo.
One more reason to use trunk based development. Or SVN.