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