Sean <seanlkml@xxxxxxxxxxxx> wrote: > On Tue, 26 Sep 2006 23:34:59 -0400 > Jeff King <peff@xxxxxxxx> 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. And with the completely distributed nature of Git I have to say that's a useful question to get an answer to. Though I believe Junio pointed out that may be incorrect by several hours for Linus' public tree due to the mirroring that occurs on kernel.org. However so long as the existance of that lag is publically stated I don't really see a problem. As Junio correctly pointed out answering that question is rather compute intensive (as Git things go) as you need to compare both the reflog for the branch in question (or all branches!) against the commit chain(s) and find where that commit became visible. Not cheap certainly but possible with the data we have. However people are ignoring the fact that receive-pack doesn't update the reflog. As of current `next` its *still* doing the ref updates by hand, rather than going through the common library code in refs.c. As a consequence its bypassing the reflog implementation. This means that `git-push` does not update the reflog. Which means there's no way Linus' public repository could have a reflog. Maybe if I (or someone else) fixed receive-pack.c Linus might consider enabling reflog, and maybe someone could fix gitweb.cgi to perform the computation - but possibly server owners wouldn't want that feature running due to its high computation cost. Especially if gitweb.cgi doesn't have a native C executable to do most of the work for it. For what its worth I keep meaning to get around to fix receive-pack.c but I just haven't done it yet. -- Shawn. - 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