4 ms·

Not OP, but Fossil is a bit more than just a VCS, it has built-in wiki, bug-tracker and a bunch of other stuff. And it keeps everything in a single file so it'

Not OP, but Fossil is a bit more than just a VCS, it has built-in wiki, bug-tracker and a bunch of other stuff. And it keeps everything in a single file so it's pretty easy to copy around out-of VCS flows. This app uses the built-in webserver to show the notes and the JSON api.

PurpleRamen 3y ago
So it's like git with builtin GitLab, as a single-file binary. How compatible is this to git and it's tooling?
- zie 3y ago
  It's mostly compatible in abilities, except, famously Fossil is not a fan of being able to change previous commits, while Git is. Fossil however is mostly incompatible with how Git thinks, since Git is arguably the worst wrapper around an API imaginable, while Fossil is pretty well thought out for smaller dev teams. Fossil will never work for Linux kernel development. see: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
  - abdullahkhalids 3y ago
    This is a beautiful document, a must read. Explains with clarity the different developmental models that fossil and git are designed for.
- myaccountonhn 3y ago
  Fossil has the ability to sync it's changes automagically to a git repo, so if you have tooling that only has git integration, you can use that.
- theamk 3y ago
  I think it's for the perfect people, who never have to amend commits, never commit to the wrong branch, only work on one branch at a time.. basically closer to SVN than GIT. If all your git interaction is via "git commit" with occasional "git checkout", then fossil could be an interesting option - it has web frontend with stuff like wiki etc.. built in. If you start working on "temp1" branch, make dozens of no-message commits and only then carefully make nice-looking PRs out of them, then fossil isn't for you. If you ever used force push to fix mistakes before anyone noticed.. then fossil isn't for you either.
  - zie 3y ago
    You actually can do most(all?) of this in Fossil, it just puts a big frowny face next to it, and highly encourages you to not change history, for hopefully obvious reasons. Some of us think actual history is more important than a persons idealized representation of the past.
  - isr 3y ago
    ??? You could just make a temp2 branch, from master at the same branching point as temp1, and then periodically create your astonishingly beautiful commits from the horridly messy temp1, to temp2. And then merge temp2 to master, when you want. The only "sin" fossil commits here is that temp1 is still there, if you want to see what you ACTUALLY did (yes, I fully accept that your beautifully crafted commits are totally bug-free). And here's the real kicker: the fossil ui is easily customizable so that certain branches (eg: "tmp-...") can be hidden from the timeline view, so they don't get in the way. I believe the sqlite team (inc DRH) have hundreds of "tmp" branches, whose only purpose is "messy commits, clean up later" (yup, you can refuse the same branch name as many times as you like, easier for auto-hiding.

PurpleRamen 3y ago

So it's like git with builtin GitLab, as a single-file binary. How compatible is this to git and it's tooling?

zie 3y ago
It's mostly compatible in abilities, except, famously Fossil is not a fan of being able to change previous commits, while Git is. Fossil however is mostly incompatible with how Git thinks, since Git is arguably the worst wrapper around an API imaginable, while Fossil is pretty well thought out for smaller dev teams. Fossil will never work for Linux kernel development. see: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
- abdullahkhalids 3y ago
  This is a beautiful document, a must read. Explains with clarity the different developmental models that fossil and git are designed for.
myaccountonhn 3y ago
Fossil has the ability to sync it's changes automagically to a git repo, so if you have tooling that only has git integration, you can use that.
theamk 3y ago
I think it's for the perfect people, who never have to amend commits, never commit to the wrong branch, only work on one branch at a time.. basically closer to SVN than GIT. If all your git interaction is via "git commit" with occasional "git checkout", then fossil could be an interesting option - it has web frontend with stuff like wiki etc.. built in. If you start working on "temp1" branch, make dozens of no-message commits and only then carefully make nice-looking PRs out of them, then fossil isn't for you. If you ever used force push to fix mistakes before anyone noticed.. then fossil isn't for you either.
- zie 3y ago
  You actually can do most(all?) of this in Fossil, it just puts a big frowny face next to it, and highly encourages you to not change history, for hopefully obvious reasons. Some of us think actual history is more important than a persons idealized representation of the past.
- isr 3y ago
  ??? You could just make a temp2 branch, from master at the same branching point as temp1, and then periodically create your astonishingly beautiful commits from the horridly messy temp1, to temp2. And then merge temp2 to master, when you want. The only "sin" fossil commits here is that temp1 is still there, if you want to see what you ACTUALLY did (yes, I fully accept that your beautifully crafted commits are totally bug-free). And here's the real kicker: the fossil ui is easily customizable so that certain branches (eg: "tmp-...") can be hidden from the timeline view, so they don't get in the way. I believe the sqlite team (inc DRH) have hundreds of "tmp" branches, whose only purpose is "messy commits, clean up later" (yup, you can refuse the same branch name as many times as you like, easier for auto-hiding.