4 ms·

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

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

by bch 5y ago

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.