On Fri, Jan 28, 2011 at 11:15, Jay Soffian <jaysoffian@xxxxxxxxx> wrote: > On Fri, Jan 28, 2011 at 10:33 AM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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. -- 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