5 ms·

I am familiar with git-new-workdir. However, git-new-workdir wasn't safe and could lose you data.

bfredl 9y ago
This is a very vague statement, and contradicts your original claim. The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. Other than that, keeping copies on another computer is the only way to reliably protect against data loss in any VCS system.
- bch 9y ago
  > Other than that, keeping copies on another computer is the only way to reliably protect against data loss in any VCS system. That’s not the point of GP post. In fossil for example, one can have multiple checkouts of a single repository (on a single computer by the same person) without fear this will lead to data loss. I don’t think this was suggested as a backup strategy, just a workflow feature.
  - bfredl 9y ago
    I most certainly didn't claim it was the point of GGP either. The point was that no evidence at all have been put forward that git-new-worktree is less "data safe" than the corresponding fossil solution, on the contrary on the design level it seems designed to be safe to use. So it seems GGP didn't mention it because it didn't fit their narrative that git lacks features. At the same time I can't claim it is guaranteed to be "no data loss" because I didn't review all the code. If you are strongly concerned about data loss you would probably use backups, _regardless_ if you use git, fossil etc.
    - bch 9y ago
      > If you are strongly concerned about data loss you would probably use backups, _regardless_ if you use git, fossil etc. Agree strongly.
- rbehrends 9y ago
  > The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. The simplest example is when the only live reference to a commit is a detached HEAD. Because HEAD is duplicated per workdir, other workdirs do not know about HEAD, and if it doesn't refer to an actual ref, it's subject to garbage collection. This isn't much of a risk if there's constant ongoing work (because then the GC grace period and the reflog will typically save you), but it can be a problem if you're dealing with a branch that sees only intermittent work. Even without that, it's pretty easy to destroy graph ancestry (which is not actual repository content, but still fairly important metadata). Example: set -e git init g cd g echo 1 >foo git add foo git commit -m test cd .. sh git-new-workdir g g2 cd g2 git checkout -b foo echo 2 >foo git commit -a -m foo git branch -d master cd ../g echo 3 >foo git commit -a -m master git log --graph --all The above script will disconnect one branch from the rest of the repository. The underlying problem is that there are some important invariants that Git needs to maintain to ensure repository integrity in the presence of mutable history, and if part of the information is held in a place that it does not know about, it may not be able to maintain those invariants. There's a reason why `git worktree` goes to a lot more effort to prevent such scenarios by registering worktrees with the repo and why `git worktree lock` is still needed.

This is a very vague statement, and contradicts your original claim. The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. Other than that, keeping copies on another computer is the only way to reliably protect against data loss in any VCS system.

bch 9y ago
> Other than that, keeping copies on another computer is the only way to reliably protect against data loss in any VCS system. That’s not the point of GP post. In fossil for example, one can have multiple checkouts of a single repository (on a single computer by the same person) without fear this will lead to data loss. I don’t think this was suggested as a backup strategy, just a workflow feature.
- bfredl 9y ago
  I most certainly didn't claim it was the point of GGP either. The point was that no evidence at all have been put forward that git-new-worktree is less "data safe" than the corresponding fossil solution, on the contrary on the design level it seems designed to be safe to use. So it seems GGP didn't mention it because it didn't fit their narrative that git lacks features. At the same time I can't claim it is guaranteed to be "no data loss" because I didn't review all the code. If you are strongly concerned about data loss you would probably use backups, _regardless_ if you use git, fossil etc.
  - bch 9y ago
    > If you are strongly concerned about data loss you would probably use backups, _regardless_ if you use git, fossil etc. Agree strongly.
rbehrends 9y ago
> The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. The simplest example is when the only live reference to a commit is a detached HEAD. Because HEAD is duplicated per workdir, other workdirs do not know about HEAD, and if it doesn't refer to an actual ref, it's subject to garbage collection. This isn't much of a risk if there's constant ongoing work (because then the GC grace period and the reflog will typically save you), but it can be a problem if you're dealing with a branch that sees only intermittent work. Even without that, it's pretty easy to destroy graph ancestry (which is not actual repository content, but still fairly important metadata). Example: set -e git init g cd g echo 1 >foo git add foo git commit -m test cd .. sh git-new-workdir g g2 cd g2 git checkout -b foo echo 2 >foo git commit -a -m foo git branch -d master cd ../g echo 3 >foo git commit -a -m master git log --graph --all The above script will disconnect one branch from the rest of the repository. The underlying problem is that there are some important invariants that Git needs to maintain to ensure repository integrity in the presence of mutable history, and if part of the information is held in a place that it does not know about, it may not be able to maintain those invariants. There's a reason why `git worktree` goes to a lot more effort to prevent such scenarios by registering worktrees with the repo and why `git worktree lock` is still needed.