Hacker News Reader

Comment by ndegruchy | Hacker News Reader

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

View on HN

(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.

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.

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.

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.

In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?

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'

- 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.

> - 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.

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

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.

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

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.

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).

Reply on news.ycombinator.com