From: Sean Date: Wed, 27 Sep 2006 06:15:29 GMT Subject: Re: git and time Message-ID: In-Reply-To: <20060927055216.GA28490@coredump.intra.peff.net> On Wed, 27 Sep 2006 01:52:16 -0400 Jeff King 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