4 ms·

I'm not sure I agree that history is "naturally" a series of diffs. Recording snapshots is natural enough for me; you just store whatever the state is at commit

I'm not sure I agree that history is "naturally" a series of diffs. Recording snapshots is natural enough for me; you just store whatever the state is at commit time. Diffs are generated by comparing two different states. No version control stores all the changes you make between two commits, only an approximation of them to get from one state to another. Git's "problem" is that you can get identical content via different routes, but due to the way git fundamentally works, history is part of the snapshot and two snapshots with identical contents but different ancestry are not the same. Actually implementing a system that handles this properly is far from trivial, and git makes the tradeoff in favour of implementation simplicity.

morelisp 5y ago
> I'm not sure I agree that history is "naturally" a series of diffs. GP cites rerere as evidence it is, and I'm inclined to agree - at least when I'm merging. During a few operations like a bisect, I probably view history as snapshots. But during merges and rebases, I definitely view it as diffs; I question whether someone can even explain these operations abstractly without resorting to a diff-based explanation. And I merge/rebase 100x more than I bisect.
pmeunier 5y ago
Storage is not really the issue here. If you merely think about snapshots, all this is fine. The problem come when you merge and rebase your snapshots, possibly solving conflicts in the process. Then none of this snapshot thinking makes sense. And actually, Git knows that well, since its default merge algorithm diffs the tips of branches with the youngest common ancestor. And rebase "replays" diffs (how would you "replay" snapshots?).
Smaug123 5y ago
Suppose I type a line into a file, and then I ask you what I just did. If you answered "You updated the contents of the file from <complete contents of the file> to <complete contents of the file>", I'd look at you like you were insane. An actual human would answer "You added the line <blah> at position <blah>", or "You added the line <blah> after the line <blah>", or similar. So I claim that very small changes are obviously thought of as diffs. And what is a large change but a composition of small changes? Pijul's model naturally represents the process of creating a change - you could slice up the diff as small as you liked without anything about the mental model changing, down to individual keystrokes if need be - whereas Git's model gets more and more unnatural when you do that.

morelisp 5y ago

> I'm not sure I agree that history is "naturally" a series of diffs. GP cites rerere as evidence it is, and I'm inclined to agree - at least when I'm merging. During a few operations like a bisect, I probably view history as snapshots. But during merges and rebases, I definitely view it as diffs; I question whether someone can even explain these operations abstractly without resorting to a diff-based explanation. And I merge/rebase 100x more than I bisect.

pmeunier 5y ago

Storage is not really the issue here. If you merely think about snapshots, all this is fine. The problem come when you merge and rebase your snapshots, possibly solving conflicts in the process. Then none of this snapshot thinking makes sense. And actually, Git knows that well, since its default merge algorithm diffs the tips of branches with the youngest common ancestor. And rebase "replays" diffs (how would you "replay" snapshots?).

Smaug123 5y ago

Suppose I type a line into a file, and then I ask you what I just did. If you answered "You updated the contents of the file from <complete contents of the file> to <complete contents of the file>", I'd look at you like you were insane. An actual human would answer "You added the line <blah> at position <blah>", or "You added the line <blah> after the line <blah>", or similar. So I claim that very small changes are obviously thought of as diffs. And what is a large change but a composition of small changes? Pijul's model naturally represents the process of creating a change - you could slice up the diff as small as you liked without anything about the mental model changing, down to individual keystrokes if need be - whereas Git's model gets more and more unnatural when you do that.