3 ms·

"The interesting part is that these systems think in terms of changes, not in terms of versions." Not git. Git's repository model is very strongly snapshot-ori

by praptak 17y ago

"The interesting part is that these systems think in terms of changes, not in terms of versions." Not git. Git's repository model is very strongly snapshot-oriented. Of course the whole machinery for supporting changesets exists in git, but it is built atop a system that actively avoids "thinking" in terms of changes. Linus on this: http://marc.info/?l=linux-kernel&m=111314792424707 http://marc.info/?l=linux-kernel&m=111314792424707

schacon 17y ago
The storage model does not - it is not file-delta based, like SVN and Mercurial. However, you as a developer can (and often do) think of the commits in terms of a changeset or "work introduced" - this is evident in tools that exist like 'rebase' which treats each commit in a branch as a patch and the collection of unique commits on that branch as a patch series and helps you transfer that series elsewhere. The 'cherry-pick' command is similar - it enforces your thinking of each commit as a changeset or patch to what came before it.
weavejester 17y ago
I don't think that link contradicts Joel. Git represents repositories as a network of diffs, not a linear history of versions.
- praptak 17y ago
  This is not true for git's object model (which I believe maps to Joel's "user model".) Quote The Git Book: "Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git." Source:http://book.git-scm.com/1_the_git_object_model.html http://book.git-scm.com/1_the_git_object_model.html However the diffs are there below the snapshot-based model as means of effectively storing and transmitting the snapshots.
  - nas 17y ago
    Conceptually git thinks about snapshots of trees. The pack format uses deltas but that's a mostly hidden detail. The pack format didn't exist for the first months of git's existence. I haven't bothered to read the blog post (Joel strikes me as someone with a huge ego and without any exceptional insights), but doesn't the above fact mostly refute his thesis? I like git and hg but they are just tools. You could do the same development model with patches.

by praptak 17y ago

schacon 17y ago

The storage model does not - it is not file-delta based, like SVN and Mercurial. However, you as a developer can (and often do) think of the commits in terms of a changeset or "work introduced" - this is evident in tools that exist like 'rebase' which treats each commit in a branch as a patch and the collection of unique commits on that branch as a patch series and helps you transfer that series elsewhere. The 'cherry-pick' command is similar - it enforces your thinking of each commit as a changeset or patch to what came before it.

weavejester 17y ago

I don't think that link contradicts Joel. Git represents repositories as a network of diffs, not a linear history of versions.

praptak 17y ago
This is not true for git's object model (which I believe maps to Joel's "user model".) Quote The Git Book: "Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git." Source:http://book.git-scm.com/1_the_git_object_model.html http://book.git-scm.com/1_the_git_object_model.html However the diffs are there below the snapshot-based model as means of effectively storing and transmitting the snapshots.
- nas 17y ago
  Conceptually git thinks about snapshots of trees. The pack format uses deltas but that's a mostly hidden detail. The pack format didn't exist for the first months of git's existence. I haven't bothered to read the blog post (Joel strikes me as someone with a huge ego and without any exceptional insights), but doesn't the above fact mostly refute his thesis? I like git and hg but they are just tools. You could do the same development model with patches.