3 ms·

diff model - considered harmful For me, the incongruity between the way git was supposed to work, based on the idea that it stored deltas, and actual observed

diff model - considered harmful For me, the incongruity between the way git was supposed to work, based on the idea that it stored deltas, and actual observed behavior was maddening. More than once I completely ripped out a git repo just so I could get around the stupid merge conflicts I would end up with on a single user project. We should always teach that git stores snapshots, and shows diffs as a convenient fiction for the user.

kelnos 3y ago
I suppose that depends on what matters to the user. I'm not trying to deny you your experience, but I don't think (in 15+ years of use) that knowing that git stores snapshots (and not diffs) has ever really made much of a difference to me. A commit to me is still a diff. When I commit something, conceptually -- to me, at least -- I'm storing a change, not a new snapshot. Because I didn't create a new empty directory on my hard drive and then retype everything, in the new state that I wanted. I took the existing code and modified it to the new state. How git stores that is not relevant to what I actually did.
- Karellen 3y ago
  OK, but if you do some work, and make a backup with `tar -cf ../.tars/backup-001.tar .`, then do some more work, and make another backup with `tar -cf ../.tars/backup-002.tar .`, then you also didn't create a new empty directory and retype everything, but you'd still be storing snapshots, not changes. (Which is also one way to think about how git conceptually handles it.)
- mikewarot 3y ago
  I often had "merge conflicts" which I didn't know how to resolve. I thought I had to undo any changes before the delta could be applied. I've wasted more energy and effort as a result, than I like to think about. Had I known I could just force a new snapshot, I wouldn't have had to nuke the .git folder and it's contents to start a new repo, trash the GitHub copy, and start it over, etc.
deleted 3y ago
[deleted]

kelnos 3y ago

I suppose that depends on what matters to the user. I'm not trying to deny you your experience, but I don't think (in 15+ years of use) that knowing that git stores snapshots (and not diffs) has ever really made much of a difference to me. A commit to me is still a diff. When I commit something, conceptually -- to me, at least -- I'm storing a change, not a new snapshot. Because I didn't create a new empty directory on my hard drive and then retype everything, in the new state that I wanted. I took the existing code and modified it to the new state. How git stores that is not relevant to what I actually did.

Karellen 3y ago
OK, but if you do some work, and make a backup with `tar -cf ../.tars/backup-001.tar .`, then do some more work, and make another backup with `tar -cf ../.tars/backup-002.tar .`, then you also didn't create a new empty directory and retype everything, but you'd still be storing snapshots, not changes. (Which is also one way to think about how git conceptually handles it.)
mikewarot 3y ago
I often had "merge conflicts" which I didn't know how to resolve. I thought I had to undo any changes before the delta could be applied. I've wasted more energy and effort as a result, than I like to think about. Had I known I could just force a new snapshot, I wouldn't have had to nuke the .git folder and it's contents to start a new repo, trash the GitHub copy, and start it over, etc.

deleted 3y ago

[deleted]