On Tue, 26 Sep 2006 21:50:51 -0700 Junio C Hamano <junkio@xxxxxxx> wrote: > 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. Well, yes. And all of my examples have assumed the example of Linus' repository where there is only one branch. So yes, in the case where there are more than one branch, you want to be able to ask the more specific question, when did this commit arrive into this repo-branch. But that is really the minutia of the issue. First we have to agree that users _do_ want to know the date of commits beyond just those recorded inside the commit itself. If we do agree on that point, then the rest is just the details of how plausible it is to provide those answers. Shawn has made it clear that the reflog doesn't really have all the information we need yet. On top of which it would be expensive to compute etc. Sean - 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