Matthew L Foster <mfoster167@xxxxxxxxx> writes: >> 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? I do not know what Jeff meant by snapshot vs changeset, so I would not comment on this part. > 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? Each commit object in git records two timestamps. When the author made that change, and when the change was made into a commit object in _some_ repository. I _think_ gitweb shows the latter, but I haven't checked, so Jakub is CC'ed. What you want to know, when a particular change has become part of the history of one branch in one repository, is not something a git commit object records. Enough people wanted to know that information, so ref-log was introduced. When it is enabled on a branch, ref-log records when the tip of the branch changed from what commit to what other commit. But it primarily is meant to answer this question: "what commit was at the tip of this branch at time T?" So if Linus had enabled ref-log in his public repository, and if gitweb knew to look at ref-log, then gitweb _could_ iterate over ref-log records for the "master" branch of Linus's repository, find the earliest one that makes the tip of the "master" branch a descendant of that security fix X, and report the time of that change. It could certainly do that. I have to warn you that this is fairly expensive, and also I happen to know that Linus does not have ref-log enabled on his public repository. Having said that, I doubt the question "when did Linus's tree saw this security fix X commit?" has much practical value. For one thing, the time he merges the side branch that has the security fix and the time he pushes out the resulting mess^Wtree out to the public repository is different. After pushed out to the public repository, it takes time for that to mirror out for public view. From the consumer's point of view, the time it finishes mirroring out _is_ the only timestamp that matters, but that mirroing happens outside of git so even if ref-log showed timestamp from the repository Linus pushes to, it would not reflect the time the general public first saw "Linus's official version that contained that fix". What people would often want to know is "Does v2.6.18-rc5 include that fix?" which is a similar but different question. This is something gitweb _could_ answer without using ref-log, and gitk already knows how to answer it. I somehow thought that it was possible to get "the latest tag that precedes this commit" (aka "git describe") for each commit by visiting its commitdiff_plain page, but I do not see it now. Can somebody tell me if I am hallucinating? - 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