On Wed, Sep 27, 2006 at 01:04:37AM -0400, Sean wrote: > 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. Yes, that is what I was trying to point out by making the branch/repo distinction in my previous mail. > 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. We should be able to make a naive space-time tradeoff: whenever a ref is updated from X to Y at time T, for each commit C in X..Y, mark the tuple (ref, C) with time T. Assuming a reasonably packed format (20 bytes of SHA1, 4 bytes of time, sorted into .git/time-cache/master) the git repository would require less than 1M per branch. Updating the ref becomes much more expensive, but looking up the value is quite cheap. Of course, rewinding would make this more complicated. I'm still not convinced this approach is worth the effort. -Peff - 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