Re: git and time

[Linus Torvalds <torvalds@osdl.org>]

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