"Clean history" is not a principal reason for VCS. "Full history so you don't accidentally lose something and can revert to any point" is the principal reason. When "clean history" conflicts with "full history", the choice should always defer to the latter. Rebase clearly breaks the full history principle.

Part of not losing stuff and reverting is being able to find stuff and precisely revert.

There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word.

If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well prepared, atomic changes where at each point the software is actually functional.

Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.

There are a lot of reasons to make a commit other than wanting to make an atomic change meant to be integrated onto shared repository. Ignoring those is just silly.

I never said otherwise. I agree 100%, but this seems like an orthogonal point to what we're discussing here.

I make a commit whenever I want to save my progress, and rarely is it ever in a state that could even be called a "version" of the software that one would want to revert to, until my feature branch is complete and ready for code review.

At that point I have a much better idea of the scope of my changes, and I can revise them into a few coherent commits, rather than a mess of "WIP" commits that are not a useful history to keep.

> and I can revise them into a few coherent commits,

Why bother with this step at all? It's literally pointless and serves only to stroke a silly aesthetic preference.

> rather than a mess of "WIP" commits that are not a useful history to keep.

I also disagree that WIP commits are not useful history. You might have explored 2 or 3 different abstractions to solve a problem, and picked one but it turned out to be the wrong one, and one of the others would have been a better choice, but now you've lost the history where you explored these options. Are you suggesting it's no loss to erase those other commits and the context around which you thought it wasn't a good choice?

The principal reason for VCS has nothing to do with "history" at all. It has all to do with "versions".

What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time. When you hack on some codebase and throw things at wall to see what sticks, you want to be able to go back to the previous attempt should your next one turn out to be useless. You may even want to commit things just because it's a convenient way to send things to be built by CI - so you basically produce "versions" to test.

But when you collaborate with others to develop a project, nobody cares about whether you made typos during your hacking session and had to come back to fix them. It's not a useful information and it never becomes a "version" of a shared project, because why would it? It's just confusing and wastes people's time on review, and makes things like blame and bisect harder to use.

Or when you put a tutorial under a git repo, with each commit representing the next step to achieve a certain outcome. You may have tweaked each step gazillion of times to perfect it, but that "history" is completely irrelevant for the resulting repo. It's meant to store "versions", not "history". Those may correlate, but don't have to.

A git repo is a data structure that you operate on. Treat it as such and use to achieve your goals.

What's funny is that "squash on merge" strategy gets you worst of both worlds. You don't get nicely curated versions in your project because if someone actually cared to fine-tune their MR you just throw that information away, and the rest doesn't care in the first place anyway. Rebasing and squashing is an incredibly useful tool for everyday use by developers in their work, but it often gets used as a band-aid for lazy developers instead.

> What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time.

In other words, the history.

> It's not a useful information and it never becomes a "version" of a shared project, because why would it?

Because the real world doesn't match your ideal of how software development works. You need the full history because sometimes innocuous looking "simple fixes" are neither innocuous nor fixes, and because obscuring the history makes auditing and merges more difficult, not less.

> It's just confusing and wastes people's time on review, and makes things like blame and bisect harder to use.

So blame and bisect are poorly written therefore you should hack around them using a convoluted process that obscures the true history and raises the risk of requiring people to redo weeks worth of work by overwriting branch histories on shared repos. Great idea.

The authors of Fossil and Sqlite did a complete breakdown of everything wrong with rebase and what a proper tool should do, so I won't belabour the point further:

https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

> In other words, the history.

Yes, that was my point. Have you read it?

> You need the full history because sometimes innocuous looking "simple fixes" are neither innocuous nor fixes, and because obscuring the history makes auditing and merges more difficult, not less.

Obscuring logically split and curated commits makes auditing and merges more difficult. Obscuring pointless edit history of the developer makes them easier.

> So blame and bisect are poorly written therefore you should hack around them using a convoluted process that obscures the true history and raises the risk of requiring people to redo weeks worth of work

blame and bisect are powerful tools that can work sensibly in various repository topologies. However, if you're either intentionally putting garbage into your topology, or not utilizing it because of ill-defined idea of "clean history", you're simply doing yourself a disservice.

> by overwriting branch histories on shared repos. Great idea.

Who said anything about overwriting branch histories on shared repos? It has its uses too (it can be useful in some cases when you're a downstream working on a project maintained upstream, for example), but it's not what most projects will ever want to do. That's not what rebase is there for.