> Except then it’s not a history of what actually happened?
What do you mean? Hg and Fossil don’t capture what “actually happened” either, they don’t show you stuff you typed and deleted before committing. They don’t save the compile errors you had or what you tested and changed. They don’t save what you said to your coworkers about their code because they were afraid to set their changes in stone or make a mess. They don’t prevent anyone from putting things into the commit log in a different order than they “actually happened”, and they can’t: these are systems that record only what you tell them. What problem, exactly, does trying to capture ‘what actually happened’ help solve?
I don’t understand this obsession with what “actually happened”, as if there’s something critical about auditing keystrokes, as if the working code and the state of the tree are secondary. No DVCS can prevent someone from designing what their commit history looks like. In the mean time, the idea that you shouldn’t be able to edit or change anything locally before showing it to other people seems like a negative force against the basic safety net that a version control system needs to provide. (And no existing DVCS actually prevents rewriting history anyway, they just claim to have preferences and they offer commands to rewrite history that have other names and say honor system, you shouldn’t use them very often.)
> revising it to make it look “clean” doesn’t actually help with anything.
Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect? You don’t care if people interleave different topics in their branches, or make lots of 1-line fixup commits all over the place? You don’t care about how long it takes to find out who changed something, or whether you have to sift through a mountain of garbage to find it?
Don’t the DVCSs that have the ‘history is sacred’ dogma also have tools to make presenting and viewing history less noisy than the so-called ‘what actually happened’ commit log? Doesn’t that prove that a clean view of history does help, and is something a lot of people want?
> What do you mean? Hg and Fossil don’t capture what “actually happened” either, they don’t show you stuff you typed and deleted before committing.
They show you what you actually committed and don't allow you to do stupid things that might corrupt your repository, which is what matters.
> I don’t understand this obsession with what “actually happened”, as if there’s something critical about auditing keystrokes, as if the working code and the state of the tree are secondary.
"Working code" and important milestones in the state of the tree are tracked by tags, bookmarks and other features depending on what source control system you use. The state of the tree at every single commit point is an irrelevant detail.
> No DVCS can prevent someone from designing what their commit history looks like.
Correct, and they shouldn't encourage you to waste your time trying to do so, and so shouldn't make it easy either.
> Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect?
I've been doing it for over 20 years, first with subversion, then Mercurial. Never had any issues figuring out what was going on. Taking a few extra minutes here and there to scan through such changes is nothing compared to trying to fixing a repository corruption, which is something I recently had to deal with.
Everything you describe can be handled by 1) a better commit log history tool and more importantly, 2) better development practices that requires adding proper comments and tickets to code and commits that describe context and rationale for changes. Opening up history to revisions is a sledgehammer trying to solve a bunch of distinct problems that require better solutions.
> Doesn’t that prove that a clean view of history does help, and is something a lot of people want?
Of course it helps, sometimes. As I've described above, that doesn't mean you should introduce a sledgehammer for the occasional pain point that can be addressed by other, arguably better means.
> They show you what you actually committed and don't allow you to do stupid things that might corrupt your repository, which is what matters.
Who cares what you actually committed on a per-commit basis, especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no innocuous accidents? Who needs to preserve the already arbitrary order of commit commands, and why? I’ve never heard a compelling and real-world reason to need this, nor any popular workflow that this idea establishes or improves.
And what repo corruption are you talking about? I don’t know about you, but one thing people espousing this ‘what actually happened’ philosophy and trying to trash-talk git tend to deliberately overlook is that git commit histories are immutable, and rebase only produces a new commit lineage, with an in-tact backup of the previous lineage surviving anything you do. It’s not possible for the history to be irrecoverably corrupted, unless you’re unfairly including bugs or hardware failures. Recovering from rebase mistakes is simply a matter of learning where the undo knobs are, and ultimately they are pretty easy to use, it’s no more work and no different outcome than learning how to groom the presentation history of Hg or other systems.
> especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no innocuous accidents?
Follow-up fixes reveal important nuance and implicit assumptions that shouldn't be erased.
As for your other claims of "simply" and "easy", you need only peruse this thread that covers plenty of rebase stories losing entire commit histories and requiring redoes of weeks worth of work to see either it is neither easy or simple.
Replying to your later edit. I’m aware of Fossil’s language, which is pretty hyperbolic. It’s largely a straw-man argument, because Fossil devs have presumed to state the intentions of git devs and git users, and they jump to a bad-faith conclusion in order to state their opinion that Fossil is better than git. Keep in mind the Fossil pages are marketing, and they are comparing themselves to the competition (git) by trying to paint git in a negative light, with prejudice. They wish they had the market share that git does, and so you should trust that language just as much as you trust a Pepsi TV commercial. Dr. Hipp has stated on HN his belief that editing code history should be considered a criminal activity, without sufficient justification for such an extreme and unique point of view.
BTW I have a ton of respect for SQLite and Dr. Hipp’s work. I love the way he has talked about testing. Nonetheless, I’m very much not a fan of their trash-talking of git that intentionally ignores the context, guidance, and real-world usage of rebase. The irony of them saying that git rebase is “dishonest” is that they themselves are being intentionally dishonest about how they talk about git, and I find it very off-putting and hypocritical, to be as polite as possible.
> Follow-up fixes reveal important nuance and implicit assumptions that shouldn’t be erased
That’s definitely not always true. In my experience that’s a small minority of cases, and when it happens, I keep the important nuance commits and don’t squash them. Nobody is forcing you to squash, it’s an option for the (many) fix up commits that were pure accidental oversight and have no nuance that needs to be preserved.
I’ve seen lots of people claim they lost work, because they freaked out or gave up without slowing down to think carefully. The reason is because they didn’t learn how git actually works, and never learned the undo buttons. I’m well aware that git’s CLI is intimidating and unintuitive, but one thing it does not do is corrupt your repo for you. That’s effectively a blaming excuse for not having learned how it works.
