I’ve tried Fossil a number of times, but several oddly-rigid aspects always manage to turn me off. Take, for example, the integrated bug tracker, which is novel and a big draw for me. Say I write up a bug and then notice an error in the description… I can’t edit it! I can merely append more comments, which also can't be edited or removed. The recommendation I found was that I should close (there's no delete!) the bug and create a new one. What’s the point of that level of immutability? I can tolerate the purity for the source code (e.g., the whole no rebase position they've taken), but for project metadata, I need way more freedom.
It’s a cool app that I’d love to use, but there are a few showstopper oddities.
You can't edit descriptions!? I was curious about Fossil but I just noped right out.
Can you share the other issues you encountered? I need to write some notes to my future self for when I stumble upon Fossil again.
Edit:
I couldn't help it and gave Fossil a try just to see what the editing was like. I changed my view.
The "description" you enter when opening a ticket seems to be just an initial comment. So when you edit the ticket, you are able to add new comments, but not edit existing ones like the initial description.
This isn't bad, it's just a different workflow with different tradeoffs. Personally, I'm used to tickets where I can add comments and also update a main Description with the current state of things. That's not how Fossil's ticketing system works though and it's intentional.
I think it would be great for Fossil to have editable comments that are somehow versioned, plus an independent Description field that can be edited and versioned like other fields, but it doesn't. And I don't think they should have to go and add a large amount of complexity to do the versioning of a description field + comments like you (and I) would prefer just because.
So I think you are criticizing the issue (immutable, append-only comments) with partial understanding about how it works and how it compares to a completely different feature you are familiar with in other ticket systems (mutable/versioned description, plus mutable/versioned appendable comments). I do think Fossil has room to improve in this area, however.
Sure, but parts of the ticket are editable. I can change the title and various fields, and everything gets versioned. But they've elected to not provide an editable description field, and instead, all clarification must be in append-only, immutable comments. This seems like an arbitrary limitation.
Well, files in the project can be synchronized across spacetime without conflicts but you can presumably edit their contents so this is a conscious design decision, not a technical one
For another perspective: It's been maybe 6 years of pretty consistent commandline usage, and I pretty much do not have to look up anything.
I usually do feature branches, so the operations Im talking about are push/pull, commit, merge, rebase, bisect, and cherry-pick. They each have a few flags, and a few positional arguments.
Realistically, they dont have to be intuitive. You learn them once by going through a small book like the git book, and you wont really forget them if you use them regularly.
The checkout/reset concept is severely and confusingly overloaded/overlapping. Addition is confusing as well, although not to that extent.
Changes can be in many states, and many operations can be applied (all the permutations of: in/off index, deleted, changed, added), but the UX has never been (re-)designed for usability, so that it's extremely confusing to remember what to use.
As I said, I have a totally different experience. I never had a day where it 'clicked' or anything, I just feel I understood the model and now it makes sense.
Agreed, I use command line for basic tasks, then git-cola for committing for a basic UI.
Before git I used svn, and must say the main thing I'm happy about git is how easy it is to just push a repository wherever, and GitHub having perfect timing to help it become a staple (at the time they didn't have private repos, but was still good).
I have a whole bunch of shell aliases for my day to day use, mostly around branches (where I work we use GitHub, and opensource projects who use git use branches for PRs/MRs/etc).
It's always fascinating when someone building something yak shaves a project of major skill on the way. Both git and fossil would be notable on their own, but the respective authors simply needed a tool for Linux and Sqlite.
Really raises the boundary for what a software engineer can do. Very inspiring.
TeX was also built for TAOCP. Crazy stuff. Really makes me want to write code. Love it.
People like to hate Git, but I guess that's because everyone uses it. I'm using Git, mostly with Idea UI, but sometimes with CLI and it's absolutely fine for me. I understand how Git works (the whole concept of commits, parents and so on), I follow some sane rules to prevent commit graph from turning to spaghetti and I never have any issues, it just works for me, 100% reliably.
If you don't go off the well trodden path, git works perfectly well. It's only when you have some special thing you do that is snowflake where you hit issues or unintuitive commands.
I tried to use Fossil for personal projects but it didn’t work for me.
Idea is very appealing but in the end I found way too many distractions, especially in solo dev environment. I also agree that in group Git is standard so introducing something like Fossil might add needles friction.
But I still recommend checking it out. Some concepts are neat and might align with use cases that I don’t have.
Right now I’m experimenting with jj/jujutsu [1] and so far it works locally but I still hadn’t used the Git integration.
I’ve been using jj for at least 12 months now. Generally, I’ve enjoyed it, but it can be a wee bit dangerous with its very easy historic amendments and its easy force pushes.
I use Fossil every day for all my projects and it works great for me. Super easy to self host and has integrated Wiki, bug tracker, ticket system and a server. Very intuitive CLI too.
Realistically, though, the better choice for small teams is going to be gitlab or github.
Using anything that isn't "boring technology" is going to introduce unnecessary friction and effort, which would be better spent on creating the product, especially given small team size.
Yeah, I'd be wary of using something other than git because if you hire a new graduate, there's a much higher chance that they'll have used Git (and most likely GitHub too) than that they've used Fossil. And most repositories outside your company that you ever need to interact with are most likely Git too.
> Beginning around 2005, the need for a better version control system for SQLite began to become evident. The SQLite architect looked around for a suitable replacement. Monotone, Git, and Mercurial were all considered. But at that time, none of these supported sync over ordinary HTTP, none could be run from an inexpensive shell account on a leased server (this was before the widespread availability of affordable virtual private servers), and none of them supported anything resembling the wiki and ticket features of CVSTrac that had been found to be so useful.
This is three years before GitHub was founded, and long before tig was released.
How should other people look at us? We always have to change these core things. From proprietary source control to CVS - that was actually a good idea because it was the open source standard. Then we all changed again to SVN for reasons I can't remember and then to GIT. And indeed it is about time to change again.
For the others who have to earn the money to support these follies, it is all the same. We could as well have sticked to CVS.
More on topic. Half of the complaints are data issues (I can not see things the way want to see them). That is easy to solve without killing GIT. And the argument that it is too complex, I see the contrary evolving where everybody is following the pattern set out by Github et al.
I'd like to see Visual Studio able to use Fossil for its source control management rather than only really supporting Git. I suppose Microsoft owning Github is a major factor there, but it would be nice if there was at least an extension to do it. There's apparently one for VS Code.
It's a shame they don't use a SQLite database for version control. I know it's probably the least efficient way to store code changes but it would bring a whole new level to bootstrapping processes. Each code change would be inserted into the db by the code produced by the prior change.
> I know it's probably the least efficient way to store code changes
Not at all. Fossil's own repository (sqlite) database currently (as of this moment) has an overall compression ratio of 101:1, packing a total of 6.7GB of data into 66.5mb.
It’s a cool app that I’d love to use, but there are a few showstopper oddities.