4 ms·

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

• smartmic 5y ago
  Here is a summary of similarities and differences on Git and Fossil functionalities: https://fossil-scm.org/home/doc/trunk/www/gitusers.md 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 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.
• bch 5y ago
  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 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…)
  • vagrantJin 5y ago
    Seeing this makes me want to try out fossil now.
  • LukeShu 5y ago
    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…)
  • masklinn 5y ago
    > <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.