Had fossil recommended to me. Also read their fossil vs git page, and I found myself agreeing with everything they said.
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.
I recommend doing this.
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.
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).
You say the most basic commands, I don't understand how git add, commit, push, pull, fetch would require a look up.
It’s a cool app that I’d love to use, but there are a few showstopper oddities.
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.
That all data even the bug tracker can be synchronized across spacetime without conflicts.
Highly recommended for indie/small teams.
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.
It would be exciting as it is stable.
See point 7 on the "about fossil" page:
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.
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.
If you haven't yet, read "Donald Knuth - The Patron Saint of Yak Shaves" at https://yakshav.es/the-patron-saint-of-yakshaves/
For TAOCP Knuth also creates a new assembly language, for illustration purposes.
TeX was written in WEB, a programming language Knuth made which transpiles to Pascal.
It's based on literate programming, a programming paradigm Knuth introduced.
And Knuth developed his own font, for use by TeX, along with a system to make fonts.
Crazy stuff indeed!
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.
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.
It's fine if you don't want to use git, really.
But some of these objections don't make sense. Did you try "tig" and bare repos on a local machine/server?
> 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.
Why SQLite does not use Git (2018) - https://news.ycombinator.com/item?id=36830813 - July 2023 (439 comments)
Why SQLite does not use Git (2018) - https://news.ycombinator.com/item?id=29125934 - Nov 2021 (356 comments)
Why SQLite Does Not Use Git? - https://news.ycombinator.com/item?id=26112802 - Feb 2021 (1 comment)
Why SQLite Does Not Use Git - https://news.ycombinator.com/item?id=16806114 - April 2018 (608 comments)
