The only use of it I've seen in the wild is Ripcord (https://dev.cancel.fm/issues), which is interestingly also relatively low resource usage compared to its competitor.
I've used Fossil for all kinds of projects big (commercial Linux distributions, with installer ISO as the result of the CI/CD pipeline stored as Fossil Unversioned content artifacts) to small (a single file demo), but primarily with only a small number of developers.
Also, the self-hosting capabilities in a few MB binary are astonishing and you just don't pay for what you don't use. In my own repositories, I don't use chat nor wiki pages, but I do use forum, the ticket system and technotes.
The community and developers are very nice to answer questions too, and are open for suggestions. There is room for even further improvement and it is more a matter of someone showing up willing to develop the specific feature of the project.
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.
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.
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.
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.
I never understood why people want to change commit history in Git, so for me it won't be an issue to not have that in Fossil.
Having said that, one point of feedback on the "lying" part: I personally interpret that type of negative phrasing as pointing at a different tool and saying: "Look! They're doing it wrong!"
You make amazing tools, man! There is no need to speak negatively about the behaviour of other players if you're a fantastic player yourself. I'd personally just mention: "Git allows you to change history. Fossil is never going to allow changing history, because that could cause issues X, Y and Z. If you do need to change history for some reason, by all means try something like Git." Keep it factual, and get right back to pointing out what makes Fossil great.
I love how SQLite doesn't downplay any alternatives, it just says: "Look at me. I'm awesome. But if you need to do <unsupported thing>, you probably don't want to use me." It would be great if the Fossil website had that same awesome attitude.
TL/DR: Random guy X that never created a successful product gave marketing advice to the person who created one of the most successful products of all time. Random guy X is an idiot.
> I never understood why people want to change commit history in Git
FWIW, by and large, they don’t, not after it’s been pushed. That’s one of the major problems with this critique.
I don't interpret it as a negative statement about Git or any other version control system. I interpret it as a statement about use of the term "project history" after rebasing. I agree with him, because the phrase "history of the project" implies it's the history of the project, and that's simply not what you have. If you order a cheeseburger and they give you a chicken sandwich, maybe it doesn't bother you since you like both, but it would indeed be lying if someone asks what you're eating and you say it's a cheeseburger.
I once ordered a cheeseburger and got a “burger” without a beef patty or any other kind of meat, not even the veggie pretend meat. Just bread, sauce, pickles and a single slice of cheese.
I felt pretty disappointed with that “cheeseburger”.
Anyway, my point is that the real world lying about cheeseburgers situation is a lot worse than pulling a fast one and handing over a chicken sandwich.
I would begrudgingly have accepted a chicken sandwich.
You don’t want the ability to edit your own mistakes before showing them to other people, even if you find them before you push?
Fossil is not capturing my pre-commit keystrokes, so I can write code and delete it without turning it into a ‘transaction’. Is that lying?
What’s sacred about my local branch before I push? In practice, nobody rebases things in public branches except by accident or to fix big mistakes. Rebase is almost entirely a local pre-push workflow. Why should I be preserving my local pre-push history, and why are you calling that “project history”?
If “project history” is so sacred that all commits should be declared immutable, how do you suggest fixing accidents like someone checking in SSH keys? Is it impossible to fix security accidents in Fossil? If so, is that good?
Why is the word “lying” being used instead of saying something like “the project’s history of transactions is being changed”? Do you think the phrasing is not intentional? Do you believe it’s good faith to accuse tool writers and tool users of being deceitful for just using a tool the way it’s designed? Do you believe the write up on rebase is impartial?
I don't feel like it was clearly explained, which is why I asked those questions. There's no distinction between local private history and public history shared with others, there's no explanation for the arbitrary line drawn on transaction boundaries, or why those are more sacred than other kinds of project history. There's no clear explanation of why "project history" should be immutable, or even what constitutes "project history" exactly. It sounds generally like a good idea to keep history to me, heck I'm on board! But the reasons to be absolute about it have not at all been clearly established, only stated dogmatically.
Everyone jumping on me is defending the use of the words "dishonest", "fabricate", "white-wash", "lying", and "deceive" as though they're merely accurate and not what they are: intentional attempts to induce shame about rebase. My point is, simply, that this is spin and it's misplaced because git was not designed to take away your freedom to modify your commit history.
Do you have any better reasons to avoid rebase that don’t depend on your own negative interpretation of git’s design intent, an interpretation that contradicts git documentation?
You could be focusing on positives instead of trash talking. You could be talking about the interesting idea of providing multiple views of history, one un-editable for details and one editable for presentation. That’s interesting and useful. Instead you choose to take cheap shots at a system that was designed differently than your ideal, without acknowledging its intent. You are breaking Hanlon’s razor and consciously choosing to assuming malice... for something that has a written history of discussion about why it exists.
Are you aware that rebase openly advertises the fact that it reorders commits, and was designed that way intentionally? Are you aware that git openly makes zero guarantees about the order of transaction events, intentionally, to allow me to have control over my presentation? Are you aware that rebase is primarily used on local commits before push, and not often used after push?
I would speculate that you are aware of these things, and not simply ignorant about git. If so, that means you are lying here and now, if not it means you don’t know what you’re talking about. I think you know git’s design intent, so it seems like you are intentionally misrepresenting the design intent of rebase. The only deceit here is coming from you, ironically.
Who are you lying to, if the other people on your team expect your merges to be rebased before you push?
What history is being lied about, if no one every saw if before it was pushed, and it is never rebased after being pushed?
Rebase is not intending to trick someone, it is not concealing a truth that needs to be otherwise preserved. Rebase is not hiding something that should not be hidden. Rebase is for cleanup and fixing mistakes.
Please stop using inappropriate words. It’s completely fine to preserve your messy edit history. It’s completely fine to want to preserve your mess. But it is not “lying” to clean it up before you push.
It’s funny you suggest I’m rephrasing it, when you are the one using different (negative) language than the git manual.
rebasing is "rewriting history". where I'm from "rewriting history" is lying..
The Fossil manual is pretty clear about calling it deceit. “By discarding parentage information, rebase attempts to deceive the reader about how the code actually came together.”
> where I’m from “rewriting history” is lying...
What history? Rebase is normally used before push. Rebase is used before it’s “history” to someone other than yourself.
I don't even care that Fossil is attacking the competition, really. I am a huge fan of SQLite. I just wish this silly "lying" argument would go away. It does not put Fossil in a good light. It does not make a meaningful contribution to understanding version control workflows. It does not give git (or any other VCS) the benefit of the doubt or it's due credit in the context of it's own design decisions, even if those design decisions are inferior by today's standards or in Dr. Hipp's opinion. But, it's clear I didn't make any progress here, I'll just think about why I'm not being persuasive and try again later. This claim about lying would be just as "true" but even sillier applied to Perforce or Subversion or RCS or SCCS... think about it.
Also for the online Fossil docs, which are great.
I can’t say I agree with this though.
> 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.
I use rebase to clean up the history of my feature branches before merging to release branches.
In that sense I don’t see a moral difference between not committing my work at all until it’s complete and rebasing. It doesn’t seem like any more of a rewriting of history than just editing text before each commit.
The nice thing about rebasing is that future readers don’t need to see the 20 commits I created titled “wip” just so I could back up my work at the end of the day or push to a test server.
This is exactly the kind of dishonest hyperbole daheart mentioned.
The purpose isn‘t to deceive the reader. Does the reader really need to see the "tmp" commit I made when switching from my desktop to my laptop? I do not think so, and squashing this commit is not intended to deceive anybody. Your comment on the other hand…
In my view, what I am doing with rebase is creating project history, not changing it. The history becomes immutable and "the truth" once the feature branch is merged.
> I think that a source code repository should be a true history of a project.
You repeatedly claim this without justification. Seems like many people do not see the value in "WIP" and "tmp" commits and failed design decisions littering history.
You do provide good reasons for why this isn‘t useful though:
> So you can backspace and edit and change all you want to before typing "commit"
So you agree correcting mistakes is useful, and not everything should be recorded.
> It is useful to have a simplified overview of project history, to aid the reader's comprehension.
> 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.
Exactly.
Consider "I ate a sandwich." vs "I though about eating a watermelone (typo), but when I opened the fridge, I changed my mind and decided to make a sandwich instead. During the process I dropped my knife on the floor and had to clean it. Then I ate a sandwich."
The second one is a much more detailed and truthful account of what happened, yet it does not provide any value. The first, much shorter and easier to follow, history conveys exactly what I wanted to tell you: What I ate.
[1]: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
I haven’t been entirely persuasive here, so I’m reflecting on how to better elaborate my thoughts. The singular word “lying” isn’t really the main thrust of my objection.
Maybe the biggest issue I see still there is the assertions about the intent behind rebase, which means the intent of git’s developers and git rebase users. It’s not really true that rebase intends to “deceive”, that’s not how the authors of the feature talk about it or frame the feature. In my opinion, it’s a semantic cop-out to claim the words are factual and non-judgemental, when the negative thrust of your choice of language is evident, and when there are clearly less loaded words available to you.
It is in that sense - your assertion that the primary intent behind rebase is to deceive people - that I feel like the Fossil documentation is still not being particularly truthful with the facts.
One way to look at this is to ask what would happen if git removed rebase. Right now, if that happened, and git didn’t change anything else about it’s design, it would be somewhat frustrating and unusable. Rebase doesn’t exist on an island, and removing it would have negative consequences, and need to be replaced with other features. Git doesn’t have a way to present a clean history without rebase there. It would be awesome for Fossil’s story to note how the fundamental design is an improvement over git.
I know your framing and language is intentional because you believe strongly in the idea of preserving project history. That is an acceptable, even laudable goal. I’m for it. Git did not have that goal when it was designed, and it’s not fair to selectively leave out that fact when criticizing. Aren’t there better ways to make the point without presuming to proclaim what the intent of rebase is? Can’t the harmful implications of rebase be demonstrated rather than framing it as “fictitious”, “fabricated”, “counter-factual”? Could you talk about it without accusing innocent bystanders of “white-washing” and being “untruthful”?
BTW, I think the Pro Git book commentary isn’t that fair to hold up as evidence for two reasons - they didn’t design rebase, and they are also trying to softly address the very argument you’re putting forward, because it keeps coming around. The existence of their comments doesn’t somehow prove that git designed rebase to “lie”, it only shows that they heard you.
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.
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.
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?
It seems like quarter of the time I make a commit I mess up either a commit message or a file list, and have to "git amend". I have no idea how the sqlite devs live without the feature, they must be much more careful programmers than I am.
Generally, the compiled version (base+resultant set of amendments) is displayed to the user, but the entries which modified the commit are also available to be seen.
Git preserves a record of the origial commit, plus amendments leading up to the final - git-reflog. The reflog is however subject to periodic pruning by default - see git-gc.
That's downright wrong: https://fossil-scm.org/home/help/amend
The “SQLite connection” is manifold - indeed drh (SQLite author) used to be on the Tcl Core Team, and is an unapologetic user of Tcl. SQLite itself isn’t just “well-supported” in Tcl, it started there. drh calls SQLite “a tcl extension that escaped into the wild”, among other things, and that “...SQLite is still heavily dependent upon TCL and the ongoing support, maintenance, and enhancement of SQLite would not be possible without TCL, and would be seriously inconvenienced without Tk.” [0][1]
The ties are interesting and deep.
[0] https://sqlite.org/tclsqlite.html
[1] https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.htm...
Brad! You're alive! In case you hadn't heard: libfossil was recently revived, has been brought up to date with regards to SHA3 hashes, and got both "update" and "revert" APIs within the past week or two. The "last" major day-to-day feature it's missing is merge. We have the merge algo (it's used by update), but not yet the equivalent of the merge command. Your account is still active on the repo (https://fossil.wanderinghorse.net/r/libfossil).
Daily, across a half dozen odd repos, and it greatly simplified my life since switching from Git. My primary wish is to have the forum compatible with email. And the next would be a partial commit option akin to 'git commit -p' although I think this is missed more than it was ever used. At first, I thought the chat was an odd addition but it's being used daily on all repos, and has really improved team cohesion and productivity. The ability to view documentation changes in the browser while still in the local checkout but not yet committed has also proved quite valuable. Having the repository contained in one file is handy, and frequenting one server for all dev related work is a huge bonus. It's unbelievably easy to setup, and the command line syntax and help is highly intuitive and simple, making transition a breeze and continued use a joy. It's a great piece of software for any team working on your typically-sized repo.
Mostly moved to gitea on a home NAS for the GitHub sync capability (makes it easy to have a local copy of dependencies, etc.)
But I do miss the straightforwardness (and sometimes bluntness) of fossil sometimes. Much easier to deal with for personal projects.
There are a few other things I dislike about the design of Fossil; it doesn't have very good low level access, for one thing (there are other concerns too, although rebase isn't one of them). I have started to make my own implementation, which I intend to support the Fossil protocol and deconstruction format. Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority, while I consider it important (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it). As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts.
That's me (https://fossil.wanderinghorse.net/r/libfossil). The protocol is irrelevant to the implementation of the underlying core algorithms and data format. The sync protocol is a completely separate layer which can be reimplemented any number of ways without affecting the underlying data model. Without the core data model and algos implemented, the sync protocol is useless because it has nothing to sync.
Ergo: first implement the data model, then the sync.
> (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it)
That's a really interesting topic, actually. The core data model is 100% independent of any given schema (or storage model, for that matter), so anyone implementing a compatible (at the data model level) tool is free to use whatever storage or schema they want. The fact is, though, that libfossil could never have gotten as far as it has without re-using much of what Richard has already designed, and that includes the schema and core SCM-relevant algorithms. As a long-time fossil contributor, it's important to me that the libfossil tools be as compatible as feasible with fossil, and that means using the same schema (for better or worse).
That said: i would very much like to see the core data model implemented on top of another schema, just to see it done. Alas, i don't have the energy to create, from scratch, such a beast, nor to maintain it, so my path is one of lower resistance: re-use what's already been designed and which works well within the fossil project. i'd love to see what you have when you're ready to post it, though. (i recall you(?) posting about this in the fossil forum before - feel free to announce your project there when you're ready.)
> As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts.
What else would one call a "container of cards"? :)
The ticket system can be configured quite a bit, so I usually set it up like a todo list with: “to do, doing, done”.
Almost literally every day since Christmas break of 2007.
> I like all it offers for the relatively low resource usage.
And setting it up to run over CGI (e.g. over a $5/month shared hoster) takes about 90 seconds and requires no additional apps. That was the initial Killer Feature for me, and is still critical for me. i host dozens of repositories over CGI on an inexpensive shared hoster (https://fossil.wanderinghorse.net), and couldn't do that with any other SCM.