I've migrated to git for my personal projects, mainly because magit (emacs frontend for git) is awesome.

But fossil is a pleasure to work with, especially on Windows, because a) it comes as a single executable that one can just copy to another machine, and b) it does not require ssh or anything else to be installed.

The web interface is amazing, especially considering the size of the executable file.

Fossil have much better command line IMHO. I even started git wrapper to get rid of it's cryptic syntax.

[1]: https://github.com/severak/ginger

Regarding the multiple working copies feature, sounds the same as Git worktrees.

I took a quick scan and: it might be analogous, yes. Not sure if any subtlties apply.

The git workflow in the docs (https://git-scm.com/docs/git-worktree) looks really clunky.

Here’s what I do in fossil:

$ cd ~/work/project_x

$ fossil open ../fossils/projx.fsl (Edit, edit, edit)

$ fossil ci -m ‘descriptive msg’

(Get an idea, but for whatever reason do not want to disturb this directory)

$ mkdir ~/work/radical_idea

$ cd ~/work/radical_idea

$ fossil open ../fossils/projx.fsl <*note here there is no sense of this being an inferior or “sub” checkout*> (Edit, edit, edit)

$fossil ci -m “cool idea” —branch cool_idea # commit work to new branch

(Test..)

$ fossil co trunk #switch branch back to trunk

$ fossil merge cool_idea #merges our work from cool_idea branch into trunk branch

$ fossil ci -m ‘merge [cool_idea] for radical new feature’

$ fossil close # this working dir syncs everything necessary to the repo (../fossils/projx.fsl) and is now essentially “offline”

$ cd ..; rm -fr radical_idea

$ cd project_x (Note: this working directory now not a tip of trunk anymore…)

$ fossil update # now up to speed (Continue hacking…)

It looks to me like the main difference is that with Git you can't have multiple worktrees on the same branch. Apropos of your comment "Note: this working directory now not a tip of trunk anymore…", to Git being on the tip of a branch is a thing of note, so it doesn't ever want to accidentally invalidate another worktree's notes about being on the tip of a branch.

In Git, that'd be:

    $ cd ~/work/fossils/projx.git

    $ git worktree add ~/work/project_x master # add a worktree with the 'master' branch checked out

    $ cd ~/work/project_x

(Edit, edit, edit)

    $ git commit -m 'descriptive msg'

(Get an idea, but for whatever reason do not want to disturb this directory)

    $ git worktree add ~/work/radical_idea -b cool_idea # add a worktree with a new 'cool_idea' branch

    $ cd ~/work/radical_idea

(Edit, edit, edit)

    $ git commit -m "cool idea"

(Test..)

    $ git switch master # whoops, can't do this
    fatal: 'master' is already checked out at '~/work/project_x'

    $ # let's just do the merge in the other worktree, since we're about to switch anyway

    $ cd ~/work/project_x

    $ git worktree remove ~/work/radical_idea # or: rm -rf ~/work/radical_idea && git worktree prune

    $ git merge cool_idea

(Continue hacking…)

> <note here there is no sense of this being an inferior or “sub” checkout>

There is not in worktrees either. You can use worktrees with a bare repository for instance. It's just that for backwards compatibility and the convenience of most users a non-bare clone creates a default worktree. That's exactly what you see if you `git clone` a repository then `git worktree list`, a worktree corresponding to the working copy.

Seeing this makes me want to try out fossil now.

Here is a summary of similarities and differences on Git and Fossil functionalities: https://fossil-scm.org/home/doc/trunk/www/gitusers.md

Also quite interesting the general comparison: https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

Both sites are written from Fossil guys, so they may not be 100% neutral.