On Wed, 22 Apr 2009, Brandon Casey wrote: > 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. Exact. > 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. Git makes tradeoffs for itself. Trying to optimize by _default_ for some random backup system, or any other environmental component not involved in git usage, is completely silly. > 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. Be free to interpret my replies as me being certain of not doing such a change. Nicolas -- 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