On Tue, 26 Sep 2006, Matthew L Foster wrote: > > It's true I don't know much about git, what is the difference between a > changeset and a snapshot? Some of it is just semantic, but a lot of it has real user-visible meaning simply because of the "mental model" difference, so the semantics actually have some meaning. A lot of systems think of commits as "what changed", and thus the "changeset" mentality. A "commit" is just the combination of all changes that that commit introduced. Git very fundamentally does not think like that at all. Git thinks of a commit as a _state_, and the history that led up to that state. So instead of the commit actually containing pointers to what changed, it very much contains a pointer directly to the actual state that was committed (a "tree" in git parlance), and then a set of pointers to the "parent" commits - the commits that explain where we came from. Now, in some sense, you can ignore the difference between the two models, since you'd think that they are totally equivalent: from the git model, you can always get the "changeset" by just diffing the current state with the previous state, and conversely from the "changeset" model you can always get the "current state" by just applying the changeset to the previous state. So in that sense, it's just two different ways of looking at exactly the same thing. HOWEVER. The fact that git internally thinks in terms of "snapshots" means that it makes no sense to (for example) record a "file rename". Git figures it out on its own, by just looking at the state before and after. The great thing about that is that the exact same logic actually works even for _unconnected_ states/snapshots, in a way that a "changeset" based situation would find very hard. So this is when the otherwise semantic difference actually shows itself. You can diff between two arbitrary points in time, and git will figure out renames on its own, without actually ever looking at the changesets in between (in fact, there may not even _be_ a straight, unbroken chain of changesets between the two states). > Are you saying timestamps should be tracked separately or tracked by an > scm system built on top of git? Does/should git care about the when of a > snapshot? Git does record the timestamp, but it records it in the same way it records the "username" - in that it doesn't really _matter_ to git. It never actually affects any meaning (well, since you can query for it, it has a meaning of sorts, but it's strictly limited to any explicit queries, so if you do "git log --since=2.weeks.ago" it will use the timestamp to give you what you want, but it doesn't actually affect anything important). So think of the timestamps as just comments with a very specific format. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html