3 ms·

> patch-based VCS is the future Sorry for being ignorant, but isn't git patch-based? I always thought of git commits as patches. You can directly convert one i

by dmos62 6y ago

> patch-based VCS is the future Sorry for being ignorant, but isn't git patch-based? I always thought of git commits as patches. You can directly convert one into a patch and vice-versa.

natsch 6y ago
Not exactly, git creates a snapshot of the working tree for every commit. The clever bit is that the object store stores files by their hashes, so if two snapshots have identical files they won't be stored twice.
- shock 6y ago
  I don't know who flagged this comment and why, because this comment is correct.
cjallen88 6y ago
See related comment: https://news.ycombinator.com/item?id=13644260 https://news.ycombinator.com/item?id=13644260
dilap 6y ago
As others mentioned, while git shows you diffs, internally it's actually snapshots of the entire repo, with each snapshot listing 0 (initial commit) 1 (normal commit) or more dependencies (merges). While it works decently, the big problem with this model is its notion of dependency is too course. For example, let's say I'm working on two completely separate things, A and B, and I happen to work on A one day, and on B another, for three days, so I end up doing work A1, B1, A2, B2, A3, B3. In git, I'd end up with the following dependency graph: A3 -> B3 -> A2 -> B2 -> A1 -> B1 The problem is these are not the real dependencies! If I decide, "oh, you know what, let's drop B and try C," there's no easy way to do that. In a patch based system, instead, the actual dependencies of every commit are calculated. So in that system, I end up with the following graph: B3 -> B2 -> B1 A3 -> A2 -> A1 And then it's very easy to say things like "drop B". (A special case of this that's a big pain-point in git is cherry-picking bug fixes between branches. When you do that in git, git has no actual notion of what happened; it's not obvious looking at any given commit if it's been cherry-picked somewhere else, and you frequently get merge errors later on. If the thing you want to cherry-pick is actually multiple commits, you have to carefully go through and try to cherry-pick them in the right order. It's a huge pain point that a patch-based VCS promises to solve.)

by dmos62 6y ago

> patch-based VCS is the future Sorry for being ignorant, but isn't git patch-based? I always thought of git commits as patches. You can directly convert one into a patch and vice-versa.

natsch 6y ago

Not exactly, git creates a snapshot of the working tree for every commit. The clever bit is that the object store stores files by their hashes, so if two snapshots have identical files they won't be stored twice.

shock 6y ago
I don't know who flagged this comment and why, because this comment is correct.

cjallen88 6y ago

See related comment: https://news.ycombinator.com/item?id=13644260 https://news.ycombinator.com/item?id=13644260

dilap 6y ago

As others mentioned, while git shows you diffs, internally it's actually snapshots of the entire repo, with each snapshot listing 0 (initial commit) 1 (normal commit) or more dependencies (merges). While it works decently, the big problem with this model is its notion of dependency is too course. For example, let's say I'm working on two completely separate things, A and B, and I happen to work on A one day, and on B another, for three days, so I end up doing work A1, B1, A2, B2, A3, B3. In git, I'd end up with the following dependency graph: A3 -> B3 -> A2 -> B2 -> A1 -> B1 The problem is these are not the real dependencies! If I decide, "oh, you know what, let's drop B and try C," there's no easy way to do that. In a patch based system, instead, the actual dependencies of every commit are calculated. So in that system, I end up with the following graph: B3 -> B2 -> B1 A3 -> A2 -> A1 And then it's very easy to say things like "drop B". (A special case of this that's a big pain-point in git is cherry-picking bug fixes between branches. When you do that in git, git has no actual notion of what happened; it's not obvious looking at any given commit if it's been cherry-picked somewhere else, and you frequently get merge errors later on. If the thing you want to cherry-pick is actually multiple commits, you have to carefully go through and try to cherry-pick them in the right order. It's a huge pain point that a patch-based VCS promises to solve.)