From: Shawn Pearce Date: Fri, 28 Jan 2011 19:19:40 GMT Subject: Re: [RFC] Add --create-cache to repack Message-ID: In-Reply-To: On Fri, Jan 28, 2011 at 11:15, Jay Soffian wrote: > On Fri, Jan 28, 2011 at 10:33 AM, Johannes Sixt wrote: >> Let's define a ref hierarchy, refs/cache-pack, that names the cache pack >> tips. A cache pack would be generated for each ref found in that >> hierarchy. Then these commits are under user control even on github, >> because you can just push the refs. Junio would perhaps choose a release >> tag, and corresponding commits in the man and html histories. The choice >> would not be completely automatic, though. > > This is just for bare repos, right? Why not just use HEAD? Even on a bare repository a user might rewind his/her HEAD frequently. Caching from today's HEAD might not be ideal if you are about to rewrite the last 10 commits and push those again to the repository. That's actually where the "1.month.ago" guess came from in the patch. If we go back a little in history, the odds of a rewrite are reduced, and we're more likely to be able to reuse this pack. HEAD - X commits/X days might be a good approximation if there are no refs/cache-pack *and* gc --auto notices there is "enough" content to suggest creating a cached pack. But I do like Johannes Sixt's refs/cache-pack ref hierarchy as a way to configure this explicitly. -- Shawn.