On Wed, Nov 9, 2011 at 8:58 AM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Nov 08, 2011 at 10:40:15AM -0600, Brandon Casey wrote: > >> On Tue, Nov 8, 2011 at 5:34 AM, Felipe Contreras >> <felipe.contreras@xxxxxxxxx> wrote: >> > Has anybody seen these? >> > http://draketo.de/proj/hg-vs-git-server/test-results.html#results >> > >> > Seems like a potential area of improvement. >> >> I think this is a case of designing the problem space so that your >> intended winner wins and your intended loser loses. > > Sort of. It is a real problem space, and mercurial does have some > advantage in that area. [...] > So he may have a point that mercurial might perform better for some > metrics than git in the current state. But I think a lot of that is > because nobody has bothered putting git into this situation and done the > tweaks needed to make it fast. You can argue that git sucks because it > needs tweaking, of course, but if I were picking between the two systems > to implement something like this, I'd consider picking git and doing the > tweaks (of course, I'm far from unbiased). It is the case that the default behaviour of git gc --auto is far from optimal. I've been playing with ways to achieve both better asymptotic performance and less jitter. One part of that is choosing "good" packing parameters for a given repo. I did this in a partially automated fashion for WebKit but I think the process can be generalised. The other issue is how often you repack ancient history, the potential waste is obvious. To this end I propose a repacking strategy in the spirit of merge-sort: If you can maintain the constraint that the sizes of packs in a repo form a geometric sequence, my napkin says the amortised cost of gc is log(n). -- David Barr. -- 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