4 ms·

This is what I love about Fossil[1]. You get all of those extra tools (wiki, chat, forums, bug tracker) in the server that is also in the binary that you use to

This is what I love about Fossil[1]. You get all of those extra tools (wiki, chat, forums, bug tracker) in the server that is also in the binary that you use to manage the repo. So, if you want to serve it, just `fossil server file.fossil` or serve a whole directory of them. Or, if you want, you can just `fossil ui` and muck around yourself, locally. The server supports SSH and HTTPS interactions for cloning and pushing. All by the same people who make SQLite, Pikchr, and more. [1]: https://fossil-scm.org https://fossil-scm.org

system33- 2y ago
Yup. +1 for fossil. I wanted an issue tracker that wasn’t text files in the repo. Lots of git-based things that were heavier (gitea and friends) or hackier than I wanted. Decided to finally try out fossil and I think it’s really really neat.
- Lyngbakr 2y ago
  In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?
  - ndegruchy 2y ago
    Not tremendously. You still commit, you still push and pull. There is a history and ignore options. There is a guide written for Git users: https://fossil-scm.org/home/doc/trunk/www/gitusers.md https://fossil-scm.org/home/doc/trunk/www/gitusers.md
  - yellowapple 2y ago
    The biggest workflow differences I've noticed: - The repo normally lives outside of the worktree, so remembering to 'fossil new foo.fossil && mkdir foo && cd foo && fossil open ../foo.fossil' took some getting used to. Easy enough to throw into some 'fossil-bootstrap' script in my ~/.local/bin to never have to remember again. - For published repos, I've gotten in the habit of creating them directly on my webserver and then pulling 'em down with 'fossil clone https://${FOSSIL_USER}@fsl.yellowapple.us/foo https://${FOSSIL_USER}@fsl.yellowapple.us/foo' - The "Fossil way" is to automatically push and pull ("auto-sync") whenever you commit. It feels scary coming from Git, but now that I'm used to it I find it nice that I don't have to remember to separately push things; I just 'fossil ci -m "some message"' and it's automatically pushed. I don't even need to explicitly stage modified files (only newly-created ones), because... - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. - 'fossil status' doesn't default to showing untracked files like 'git status' does; 'fossil status --differ' is a closer equivalent.
    - chungy 2y ago
      > - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. That'd be a deal breaker for me. Git's staging area is such a breath of fresh air compared to the old way (that fossil is doing), that it's one of the biggest reasons for me to switch to it. It's completely freeing to not have to worry about things being accidentally added to commits that I didn't want to have.
      - cortesoft 2y ago
        I agree, and adding a `-a` to your git commit if you dont want to have to add all the changes is not much of an added burden for people who operate in the fossil way
      - Borg3 2y ago
        Not to mention this is kinda yet another hidden local version :) I have a habbit to do git add -u when stuff I work on is in good state and I am about to try something more risky. I just stage the stuff, and keep hacking. If I fuck it up.. I can git checkout files or everything up to a stage.
yellowapple 2y ago
That's exactly why I've been using Fossil exclusively for new projects, and have been (very slowly) migrating existing ones over as well. It ain't like my FOSS projects get a whole lot of outside contributions anyway (though I've been tinkering a bit with bidirectional Git syncs so that people can submit GitHub PRs / GitLab MRs / generic Git bundles / etc. in those rare cases).
AceJohnny2 2y ago
(tongue-in-cheek:) This is what I hate about Fossil, you get all this extra cruft (wiki, chat, forums, bug tracker) that's a worse version than dedicated software for each. It really depends on what you're optimizing for.
- yellowapple 2y ago
  Thankfully, there's not much forcing you to use much of it; the "template repo" I use outright disables forum/wiki/chat/bugtracker access to non-admin users (i.e. anyone who hasn't cracked my password), since most of the time when I throw code out into the world I don't really care all that much about supporting it - and in the cases where I do care, I can always re-enable exactly the things I want.
- ndegruchy 2y ago
  Fair enough. I usually deny permissions to the features I don't care about if I'm pushing it up on the web. It's nice to have them there if I need them, though.
lordgroff 2y ago
If Fossil let me rebase, I'd never use git for personal projects again. I love the whole all-in-one approach and it's all so functional. But the (almost extreme) hostility to a rebase workflow makes it a no go for me, and I'm sure many others.

system33- 2y ago

Yup. +1 for fossil. I wanted an issue tracker that wasn’t text files in the repo. Lots of git-based things that were heavier (gitea and friends) or hackier than I wanted. Decided to finally try out fossil and I think it’s really really neat.

Lyngbakr 2y ago
In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?
- ndegruchy 2y ago
  Not tremendously. You still commit, you still push and pull. There is a history and ignore options. There is a guide written for Git users: https://fossil-scm.org/home/doc/trunk/www/gitusers.md https://fossil-scm.org/home/doc/trunk/www/gitusers.md
- yellowapple 2y ago
  The biggest workflow differences I've noticed: - The repo normally lives outside of the worktree, so remembering to 'fossil new foo.fossil && mkdir foo && cd foo && fossil open ../foo.fossil' took some getting used to. Easy enough to throw into some 'fossil-bootstrap' script in my ~/.local/bin to never have to remember again. - For published repos, I've gotten in the habit of creating them directly on my webserver and then pulling 'em down with 'fossil clone https://${FOSSIL_USER}@fsl.yellowapple.us/foo https://${FOSSIL_USER}@fsl.yellowapple.us/foo' - The "Fossil way" is to automatically push and pull ("auto-sync") whenever you commit. It feels scary coming from Git, but now that I'm used to it I find it nice that I don't have to remember to separately push things; I just 'fossil ci -m "some message"' and it's automatically pushed. I don't even need to explicitly stage modified files (only newly-created ones), because... - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. - 'fossil status' doesn't default to showing untracked files like 'git status' does; 'fossil status --differ' is a closer equivalent.
  - chungy 2y ago
    > - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. That'd be a deal breaker for me. Git's staging area is such a breath of fresh air compared to the old way (that fossil is doing), that it's one of the biggest reasons for me to switch to it. It's completely freeing to not have to worry about things being accidentally added to commits that I didn't want to have.
    - cortesoft 2y ago
      I agree, and adding a `-a` to your git commit if you dont want to have to add all the changes is not much of an added burden for people who operate in the fossil way
    - Borg3 2y ago
      Not to mention this is kinda yet another hidden local version :) I have a habbit to do git add -u when stuff I work on is in good state and I am about to try something more risky. I just stage the stuff, and keep hacking. If I fuck it up.. I can git checkout files or everything up to a stage.

yellowapple 2y ago

That's exactly why I've been using Fossil exclusively for new projects, and have been (very slowly) migrating existing ones over as well. It ain't like my FOSS projects get a whole lot of outside contributions anyway (though I've been tinkering a bit with bidirectional Git syncs so that people can submit GitHub PRs / GitLab MRs / generic Git bundles / etc. in those rare cases).

AceJohnny2 2y ago

(tongue-in-cheek:) This is what I hate about Fossil, you get all this extra cruft (wiki, chat, forums, bug tracker) that's a worse version than dedicated software for each. It really depends on what you're optimizing for.

yellowapple 2y ago
Thankfully, there's not much forcing you to use much of it; the "template repo" I use outright disables forum/wiki/chat/bugtracker access to non-admin users (i.e. anyone who hasn't cracked my password), since most of the time when I throw code out into the world I don't really care all that much about supporting it - and in the cases where I do care, I can always re-enable exactly the things I want.
ndegruchy 2y ago
Fair enough. I usually deny permissions to the features I don't care about if I'm pushing it up on the web. It's nice to have them there if I need them, though.

lordgroff 2y ago

If Fossil let me rebase, I'd never use git for personal projects again. I love the whole all-in-one approach and it's all so functional. But the (almost extreme) hostility to a rebase workflow makes it a no go for me, and I'm sure many others.