Jeff King wrote: > On Wed, Apr 22, 2009 at 08:15:56PM +0200, Matthieu Moy wrote: > >> Nicolas Pitre <nico@xxxxxxx> writes: >> >>> Why so? Having fewer packs is always a good thing. Having only one >>> pack is of course the optimal situation. >> Good and optimal wrt Git, but not wrt an incremental backup system for >> example. I have a "git gc" running daily in a cron job in each of my >> repositories, but to be nice with my sysadmin, I don't want to rewrite >> tens of megabytes of data each night just because I commited a 2 lines >> patch somewhere. > > You can mark your "big" pack with a .keep, then do your nightly gc as > usual. You'll have a smaller pack being rewritten each night. When it > gets big enough, drop the .keep, gc, and then .keep the new pack. > > Yes, it's a bit more work for you, but having "git gc" optimize by > default for git's performance seems to be the only sensible course. > Your idea of what is "big enough" above is somewhat outside the realm of > git, so you have to pay the price to specify it by tweaking the > keep-files. But isn't git-gc supposed to be the "high-level" command that just does the right thing? It doesn't seem to me to be outside the scope of this command to make a decision about trading off speed/io for optimal repo layout. In fact, it does do this already. The default window, depth and compression settings are chosen to be "good enough", not to produce the absolute optimum repo. I'm just pointing out that everything is a trade off. So I think saying something like "gc must optimize for git's performance" is not entirely accurate. We make tradeoffs now. Other tradeoffs may be helpful. Also, don't interpret my comments as me being convinced that a change to gc should be made. It's a trivial patch, but I'm not yet certain one way or the other. -brandon -- 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