git and time

After seeing how git currently accepts a remote repository's timestamp it occurred to me that
git should probably instead prefer the time a particular changeset was committed to _this_
repository. Perhaps I don't know enough about git but it seems to me the important information is
when a particular changeset was committed to this repository, all other remote/sub/parent
repositories' timestamps are secondary (or at least should be tracked separately).

-Matt



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Hi,

On Tue, 26 Sep 2006, Matthew L Foster wrote:

After seeing how git currently accepts a remote repository's timestamp 
it occurred to me that git should probably instead prefer the time a 
particular changeset was committed to _this_ repository.

Git accepts it, but does not rely on it. Instead, it relies on 
parent-child relations.

Hth,
Dscho

Matthew L Foster wrote:

After seeing how git currently accepts a remote repository's timestamp
it occurred to me that git should probably instead prefer the time
a particular changeset was committed to _this_ repository. Perhaps
I don't know enough about git but it seems to me the important
information is  when a particular changeset was committed to this
repository, all other remote/sub/parent repositories' timestamps
are secondary (or at least should be tracked separately). 

First, the information you want is contained in reflog. Dates the head tip
got the specified value.

Second, git cannot rewrite commits (and commits contain timestamp) when
fetching commit from remote repository for performance reasons.

Third, git uses timestams as heuristics, but relies on parent information.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Tue, Sep 26, 2006 at 04:23:16PM -0700, Matthew L Foster wrote:

After seeing how git currently accepts a remote repository's timestamp
it occurred to me that git should probably instead prefer the time a
particular changeset was committed to _this_ repository. Perhaps I

If you fetch a commit from a remote repository, it does not get
"committed" to the local repository. It is simply copied. Keep in mind
that the act of making a commit means making an immutable SHA1 object.
If, when you fetched that commit, you changed some aspect of it (like
the timestamp), it would cease to have the same SHA1, and thus the DAG
of your history would differ from the remote end.

During operations where the original commit isn't preserved (e.g.,
applying patches from an email), git applies the current timestamp as
the committer timestamp (but uses the email date as the author
timestamp).

don't know enough about git but it seems to me the important
information is when a particular changeset was committed to this
repository, all other remote/sub/parent repositories' timestamps are
secondary (or at least should be tracked separately).

That information is not tracked in the commit objects (because they are
never "committed" in the local repository, only copied); however, Shawn's
reflog implementation gives some indication of when each ref changed,
which shows when some (but not all) commits made it into the local
repository.

Keep in mind that git doesn't really CARE about timestamps to do most
operations; it operates on the graph created by parentage. Think of the
timestamps more as comments; when a commit is created, we comment who
did it and when, both accordinging to their local information.

-Peff

PS Nit: Git doesn't work with changesets, it works with snapshots,
building a directed graph of snapshots. Maybe that is the source of your
confusion?

Keep in mind that git doesn't really CARE about timestamps to do most
operations; it operates on the graph created by parentage. Think of the
timestamps more as comments; when a commit is created, we comment who
did it and when, both accordinging to their local information.

-Peff

PS Nit: Git doesn't work with changesets, it works with snapshots,
building a directed graph of snapshots. Maybe that is the source of your
confusion

It's true I don't know much about git, what is the difference between a changeset and a snapshot?
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?

Perhaps my question is directed more toward gitweb.cgi, it seems to me the timestamp of when a
snapshot was merged into this repository should somehow be tracked and that is what gitweb.cgi
should default to display. For example, if someone wants to know if security bugfix X was merged
into linus' kernel tree they also want to know when that happened, don't they? 

-Matt


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

On Tue, 26 Sep 2006 17:27:45 -0700 (PDT)
Matthew L Foster [off-list ref] wrote:

It's true I don't know much about git, what is the difference between a changeset and a snapshot?
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?

Perhaps my question is directed more toward gitweb.cgi, it seems to me the timestamp of when a
snapshot was merged into this repository should somehow be tracked and that is what gitweb.cgi
should default to display. For example, if someone wants to know if security bugfix X was merged
into linus' kernel tree they also want to know when that happened, don't they? 

You are right that a "Merged Date:" in gitweb would be useful information to
show for each commit, but it's not straightforward given the design of git.

Each commit contains the date and time it was first created.  Because this value
is used as part of each commits' unique hash value, it can not be changed without
breaking a very fundamental part of Git.  This means that Git can not easily
answer the question of which date any particular commit was merged with the
local repository.

To help address this, the "reflog" feature was added (i believe by Shawn Pearce)
which records a local time stamp when pulling in changes from other repositories.
It should be possible to query this log to get the information you desire, but I
don't think it would be efficient enough to do in gitweb unless the values were
cached instead of queried each time.

Sean

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

On Tue, Sep 26, 2006 at 05:27:45PM -0700, Matthew L Foster wrote:

It's true I don't know much about git, what is the difference between
a changeset and a snapshot?

I think Linus' explanation covered what I meant, but please ask for
clarification if there was something that didn't make sense.

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?

Yes, they could be tracked separately. My point was that git deals in
immutable snapshot objects (commits) and you don't want to change the
commit objects after the fact. You could certainly make an external
mapping of "this commit object entered the repo at local time T" but I
doubt it would be of much use. See below.

Perhaps my question is directed more toward gitweb.cgi, it seems to me
the timestamp of when a snapshot was merged into this repository
should somehow be tracked and that is what gitweb.cgi should default
to display. For example, if someone wants to know if security bugfix X
was merged into linus' kernel tree they also want to know when that
happened, don't they?

Right. So you really want to know not "when did this commit enter this
repo" but rather "when did this head/branch first contain this commit"
(since there may be multiple branches within a repo).  We can find out
"does commit X contain commit Y" by looking at the commit graph. The
reflog system records "head H contained commit X at time T" so between
the two you can find the answer to your question (but it takes some
computation).

I think Junio's email explained this better than I could, but again,
please ask if something is unclear.

-Peff

On Tue, 26 Sep 2006 23:34:59 -0400
Jeff King [off-list ref] wrote:

Right. So you really want to know not "when did this commit enter this
repo" but rather "when did this head/branch first contain this commit"
(since there may be multiple branches within a repo).

Even though it's being a bit pedantic, I have to disagree with you here.
The question the user is asking is exactly, "When did this commit enter
_this_ repo?".

Because of the design of git, such a question must be converted into a
question regarding reflogs and head/branch values etc...  But the user
doesn't care anything about all that.  They're just interested in the
date/time the commit was published in the repository in question, not
the date time the commit was originally created in some distant
repo.

Sean

Linus Torvalds wrote:

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.

And if I understand correctly, that is how StGit and pg (Patchy Git), which
are patch management applications similar in the purpose to the Quilt, and
are based on Git, works.

http://wiki.procode.org/cgi-bin/wiki.cgi/StGITtheory
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git