> As soon as you do a rebase, you're rewriting history.
Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch.
> You're losing information about points of time and specific states that actually existed
If you avoid rebase, then you end up "rebasing" without rebasing. You "squash" intermediate states by never recording them to begin with.
Failing to record history is not superior to squashing it.
> And finds that it is gone without a trace.
I don't have the details, but it sounds like someone rebased a public branch. Yes that is bad. But it's sort of like saying we shouldn't drive cars because someone chose to drive the wrong direction down a 1 way road.
> Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch.
The rebase becomes part of the public branch eventually, inflicting your lies on everyone else.
> If you avoid rebase, then you end up "rebasing" without rebasing. You "squash" intermediate states by never recording them to begin with.
If only Git had a third alternative, a way to... entangle two diverging branches of history without destroying or rewriting either. You could say it would be a bit like a car merging into a highway.
> Failing to record history is not superior to squashing it.
"We don't know" is at least an honest statement. Claiming that you do but then making up some nonsense is something that the LLMs do enough of already.
I think the crux of the argument is what you think about private git commits. You may think of them as "holy" history. Assuming the commits are still private, I give them no more prestige than the editor's undo log.
What do you think of the editors undo log? It's a very real historical log. Should it be treated as "holy" history too? If not, what makes the undo log less true/important than a private git commit log?
If you did X then Y then Z, there's a difference between saying "I did Y, Z, and X" (squashing/summarizing) and "I did Y then Z then X" (rebasing).
Squashing is often dumb and unhelpful, because you're now re-summarizing the points in time that you already considered worth highlighting when they happened (when you had the most context to judge them!).
Rebasing is lying about the order and/or context that those changes happened in.
Your undo log is comparable to squashing, but not at all to rebasing.
And then again, the first-order vs second-order summarizing distinction matters, and you already capture the second-order summary in your merge commit. Squashing is just destroying information for zero practical benefit.
> private
You keep using that word, but branches are often a lot less private than you think. Push it to get a colleagues' input on something? Congratulations, it's now public. Created a pull request that you want to revise? Already public.
Do you consider it lying when a commit doesn't include all changes in the working tree at the time it was committed? How about when a committer adds a file to .gitignore?
My advice is don’t engage with the ‘rebase is a lie’ argument. It is a textbook bad-faith argument, since it deliberately and explicitly ignores the stated intention behind rebase. It’s a talking point that people like to parrot without fully understanding what the author of the argument (Fossil developers) meant, and without fully understanding the implications of the argument. FWIW, HN mods in the past have previously confirmed that repeating this hyperbolic claim goes against HN guidelines.
Fun note though, I argued this directly with Dr Hipp (principal author of SQLite and of Fossil, inventor of the ‘git rebase is a lie’ argument) and during that discussion, he agreed to soften the language on the Fossil pages. They are still hyperbolic, using the word ‘dishonest’, and continue to distort the reasons and usage behind rebase, but he did remove some instances of the word ‘lie’ and ‘lying’, which is progress.
It’s a bit of a shame that they haven’t found the strength to frame Fossil in a positive light without trash-talking the competition. There is a good-faith argument for Fossil vs git, but they’re choosing not to use it.
Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch.
> You're losing information about points of time and specific states that actually existed
If you avoid rebase, then you end up "rebasing" without rebasing. You "squash" intermediate states by never recording them to begin with.
Failing to record history is not superior to squashing it.
> And finds that it is gone without a trace.
I don't have the details, but it sounds like someone rebased a public branch. Yes that is bad. But it's sort of like saying we shouldn't drive cars because someone chose to drive the wrong direction down a 1 way road.