Sean <seanlkml@xxxxxxxxxxxx> writes: > 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. I disagree. For somebody who is tracking my "master" branch, it does not matter when some critical fix appeared on my "next" branch. The user will be vulnerable until that fix makes its way to the "master" branch. The user _can_ switch to track my "next" branch, but that is like arguing that the user can apply the same patch to his local copy that tracks my "master". I may try-pull from Paul to get updates from gitk, but usually I do that with "git fetch", not "git pull". So my repository may contain commits and blobs for the latest and greatest gitk, but until I merge it and push the result out nobody would benefit from it through my repository. See? Having a commit somewhere in the repository does not make any difference unless that commit is on some branches you care about. - 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