Comment by rbehrends | Hacker News Reader

Comment by rbehrends | Hacker News Reader

Parent Full thread

I disagree with the "progress" part. Git is still the 2005 state of the art, and in parts not even that (it took until 2015 to even support something as basic as multiple checkouts of the same repository via `git worktree`).

Git is generally not very suitable for new features, because the repository format is very restrictive and has no room for adding new metadata (it's not impossible, but it's always going to be a hack).

Most actual progress in version control has happened in systems other than Git, both open source and commercial (what Git has gotten is a lot more polish and ecosystem integration).

My general criticism of Git isn't that it's bad, but that it's the lowest common denominator of modern version control and has resulted in technology being locked in to yesterday's state. At the same time, it's awfully complicated for how relatively basic its feature set is. It is not a bad tool, but it's not a particularly attractive one, either.

Also:

> It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one.

Umm, what? Git wasn't the first attempt at improving upon CVS or SVN, and was arguably in some aspects worse than some of its predecessors (it often had higher implementation quality, but in terms of features it was also often a step backwards). I think lots of people are not familiar with PRCS (including the specced-out, but never implemented PRCS2), GNU arch, Monotone, or Darcs, not counting commercial or more esoteric ones.

> it took until 2015 to even support something as basic as multiple checkouts of the same repository via `git worktree`

This feature was supported many years before that via a separate script.

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

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.

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

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.

> If you are strongly concerned about data loss you would probably use backups, _regardless_ if you use git, fossil etc.

Agree strongly.

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

Reply on news.ycombinator.com