On Wed, 27 Sep 2006 01:52:16 -0400 Jeff King <peff@xxxxxxxx> wrote: > Yes, that is what I was trying to point out by making the branch/repo > distinction in my previous mail. Yeah, Junio's response made me realize that. Apologies. > 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. Yes. It should be relatively straight forward, and removes the need to use the reflog at all. It's the right tradeoff since the value would be queried much more often than updated. > Of course, rewinding would make this more complicated. I'm still not > convinced this approach is worth the effort. You could almost ignore rewinding without too big a problem, or at least only deal with it when performing a prune. As for being worth the effort, we'll have to see if anyone steps up to actually offer a patch. If not, you're right again :o) 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