9 ms·

Fossil looks very interesting, but I completely disagree with their [stance on rebasing](https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-

Fossil looks very interesting, but I completely disagree with their [stance on rebasing](https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md). This is a dealbreaker for me. I do not consider having 10 buggy commits per feature instead of 1 working one an advantage. It just complicates reading history and hinders debugging (e.g. bisect). I get their arguments, I just disagree.

rubyist5eva 6y ago
This is what private branches are for - when you merge them and sync they show up as a single commit on the mainline branch - not too different from git merge --squash.
- mscrnt 6y ago
  That, and it's very easy to hide commits from the timeline too. You can get most if not all the benefits of rebase without losing history—that's a good thing.
- deleted 6y ago
  [deleted]
iudqnolq 6y ago
The theory is that you don't see those 10 commits unless you choose to. I think they're right in theory that a Sufficiently Smart^TM scm should be able to work better by not throwing data away, but I haven't tested if it actually works in practice. > The Git documentation acknowledges this fact (in so many words) and justifies it by saying "rebasing makes for a cleaner history." I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.
dahart 6y ago
Agreed. In particular “Rebasing is lying about the project history” is misleading and frankly, just downright lame hyperbole. I actually want to try Fossil, but this text is so dishonest and hyperbolic, it’s off-putting and preventing me from trying Fossil. This feels like a sign that Fossil might not be focused on real world user needs. It’s not uncommon to bump into this claim in threads about git, I don’t think the Fossil devs came up with this idea, but they sure are running with it. This is an argument whose time has passed and needs to die. It’s not helpful. Please @Fossil devs, come up with better and more honest reasons to compare Fossil to git. If I don’t have to rebase again, that’s great! If Fossil avoids merge conflicts more often, and handles merge conflicts better, absolutely fantastic. But, please, come on. Rebase is “lying” exactly just as much as hitting backspace is “lying”. Am I lying if I fix a typo or a bug before I commit? Do you really want to preserve all keystrokes ever typed on your keyboard during development? Does Fossil actually capture all keystrokes? If not, then are you sure Fossil is not lying about development history by your definition? Being able to clean and organize your development history before you share it with others is an intentional feature, not a bug. Attempting to claim a moral high ground over what is purely a technical and workflow issue is making Fossil look ignorant to me, it’s doing the opposite of what you want.
- SQLite 6y ago
  I consider a version control system to be a history of a project. If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact. The history Git and in Fossil is only precise to the transaction level. A key-stroke or backspace is not a transaction. A single iteration of the edit-compile-test cycle is not a transaction. A transaction is created by the "commit" command. Git and Fossil make no record of the stuff that happens in between two commits. They only record what is in each commit. So you can backspace and edit and change all you want to before typing "commit". But once you type "commit", all that you've done since the previous commit becomes part of the permanent record. Rebase violates that constraint. It changes the permanent record. Rebase makes the repository say that the sequence of commits is different from the order in which they actually happened. You can call that whatever you like. "Telling a compelling story." "Generating a clean history." I call it "lying", since the purpose seems to be to deceive the reader about what actually happened. It is useful to have a simplified overview of project history, to aid the reader's comprehension. There is no sin in this as long as you are truthful to state that the simplified history is in fact a simplification that skips or revises some of the messy details of reality. The alternatives to rebase that Fossil provides do exactly that - they suppress the unimportant details of the history to provide a simplified and more readable history. The difference is that the original, truthful history is still provided, for auditing and for those who care. In other words, the repository reports both "what we should have done" and/or "the best way to think about what we did" in addition to "what actually happened". I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative. But I think that a source code repository should be a true history of a project. If you view a source repository as a true history, as I do, then rebase is a tool for lying about the history.
BeetleB 6y ago
First, it sounds like you're looking for squash - not rebase. This is a false dichotomy. You can have it both ways - git just doesn't provide it both ways. In Mercurial, you can squash commits so the history shows it as one commit, but you can still see the individual commits if you really want to. The history is never lost. I imagine Fossil does something similar. Looking at this subthread: Wow! People really get triggered when it comes to Git.
- dahart 6y ago
  I guess you’re referring to me, and I guess it’s fair. It has nothing to do with git though, I’m triggered when it comes to arguments that I feel like aren’t being made in good faith. Serious question though: what do you do in Mercurial, or Fossil, when someone accidentally checks in SSH keys? I’ve watched this happen in companies multiples times.
  - deleted 6y ago
    [deleted]
  - mscrnt 6y ago
    You shun the secrets-leaking commit: https://fossil-scm.org/home/doc/trunk/www/shunning.wiki https://fossil-scm.org/home/doc/trunk/www/shunning.wiki
    - dahart 6y ago
      Thanks! So... there's both shun and scrub in Fossil, which lie about project history? Or is is not accurate to call it lying in this case?
      - mscrnt 6y ago
        I don't know about scrub as it doesn't alter version history but user data such as passwords, IP addresses, etc.; but to shun an artifact definitely meets my criteria for falsifying history and thus lying. I neither suffer from cognitive dissonance nor feel the need to defend a piece of software's honour.
richie_adler 6y ago
If you watch a single branch and deactivate the "related" branches, you can avoid seeing all the "buggy commits": all merges in Fossil are what Git does when indicating "--no-ff". No branches are ever deleted, so the individual commits remain in the branch; the merge commit is always a single one.

rubyist5eva 6y ago

This is what private branches are for - when you merge them and sync they show up as a single commit on the mainline branch - not too different from git merge --squash.

mscrnt 6y ago
That, and it's very easy to hide commits from the timeline too. You can get most if not all the benefits of rebase without losing history—that's a good thing.
deleted 6y ago
[deleted]

iudqnolq 6y ago

The theory is that you don't see those 10 commits unless you choose to. I think they're right in theory that a Sufficiently Smart^TM scm should be able to work better by not throwing data away, but I haven't tested if it actually works in practice. > The Git documentation acknowledges this fact (in so many words) and justifies it by saying "rebasing makes for a cleaner history." I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.

dahart 6y ago

Agreed. In particular “Rebasing is lying about the project history” is misleading and frankly, just downright lame hyperbole. I actually want to try Fossil, but this text is so dishonest and hyperbolic, it’s off-putting and preventing me from trying Fossil. This feels like a sign that Fossil might not be focused on real world user needs. It’s not uncommon to bump into this claim in threads about git, I don’t think the Fossil devs came up with this idea, but they sure are running with it. This is an argument whose time has passed and needs to die. It’s not helpful. Please @Fossil devs, come up with better and more honest reasons to compare Fossil to git. If I don’t have to rebase again, that’s great! If Fossil avoids merge conflicts more often, and handles merge conflicts better, absolutely fantastic. But, please, come on. Rebase is “lying” exactly just as much as hitting backspace is “lying”. Am I lying if I fix a typo or a bug before I commit? Do you really want to preserve all keystrokes ever typed on your keyboard during development? Does Fossil actually capture all keystrokes? If not, then are you sure Fossil is not lying about development history by your definition? Being able to clean and organize your development history before you share it with others is an intentional feature, not a bug. Attempting to claim a moral high ground over what is purely a technical and workflow issue is making Fossil look ignorant to me, it’s doing the opposite of what you want.

SQLite 6y ago
I consider a version control system to be a history of a project. If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact. The history Git and in Fossil is only precise to the transaction level. A key-stroke or backspace is not a transaction. A single iteration of the edit-compile-test cycle is not a transaction. A transaction is created by the "commit" command. Git and Fossil make no record of the stuff that happens in between two commits. They only record what is in each commit. So you can backspace and edit and change all you want to before typing "commit". But once you type "commit", all that you've done since the previous commit becomes part of the permanent record. Rebase violates that constraint. It changes the permanent record. Rebase makes the repository say that the sequence of commits is different from the order in which they actually happened. You can call that whatever you like. "Telling a compelling story." "Generating a clean history." I call it "lying", since the purpose seems to be to deceive the reader about what actually happened. It is useful to have a simplified overview of project history, to aid the reader's comprehension. There is no sin in this as long as you are truthful to state that the simplified history is in fact a simplification that skips or revises some of the messy details of reality. The alternatives to rebase that Fossil provides do exactly that - they suppress the unimportant details of the history to provide a simplified and more readable history. The difference is that the original, truthful history is still provided, for auditing and for those who care. In other words, the repository reports both "what we should have done" and/or "the best way to think about what we did" in addition to "what actually happened". I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative. But I think that a source code repository should be a true history of a project. If you view a source repository as a true history, as I do, then rebase is a tool for lying about the history.

BeetleB 6y ago

First, it sounds like you're looking for squash - not rebase. This is a false dichotomy. You can have it both ways - git just doesn't provide it both ways. In Mercurial, you can squash commits so the history shows it as one commit, but you can still see the individual commits if you really want to. The history is never lost. I imagine Fossil does something similar. Looking at this subthread: Wow! People really get triggered when it comes to Git.

dahart 6y ago
I guess you’re referring to me, and I guess it’s fair. It has nothing to do with git though, I’m triggered when it comes to arguments that I feel like aren’t being made in good faith. Serious question though: what do you do in Mercurial, or Fossil, when someone accidentally checks in SSH keys? I’ve watched this happen in companies multiples times.
- deleted 6y ago
  [deleted]
- mscrnt 6y ago
  You shun the secrets-leaking commit: https://fossil-scm.org/home/doc/trunk/www/shunning.wiki https://fossil-scm.org/home/doc/trunk/www/shunning.wiki
  - dahart 6y ago
    Thanks! So... there's both shun and scrub in Fossil, which lie about project history? Or is is not accurate to call it lying in this case?
    - mscrnt 6y ago
      I don't know about scrub as it doesn't alter version history but user data such as passwords, IP addresses, etc.; but to shun an artifact definitely meets my criteria for falsifying history and thus lying. I neither suffer from cognitive dissonance nor feel the need to defend a piece of software's honour.

richie_adler 6y ago

If you watch a single branch and deactivate the "related" branches, you can avoid seeing all the "buggy commits": all merges in Fossil are what Git does when indicating "--no-ff". No branches are ever deleted, so the individual commits remain in the branch; the merge commit is always a single one.