On Sun, Nov 25, 2012 at 8:27 AM, Thorsten Glaser <tg@xxxxxxxxxx> wrote: > tl;dr: I would like to have a *global* option for git to restrict > the number of threads of execution it uses. Several subcommands, > like pack-objects, are already equipped with an optioin for this, > but unfortunately, these are seldom invoked by hand¹, so this can’t > work in my situations. See the git-config man page. The number of threads that pack uses can be configured in the global or system gitconfig file by setting pack.threads. e.g. $ git config --system pack.threads 1 Also, modern git accepts a '-c' option which allows you to set configuration options on the command line, e.g. 'git -c pack.threads=1 gc'. The other setting you should probably look at is pack.windowMemory which should help you control the amount of memory git uses while packing. Also look at core.packedGitWindowSize and core.packedGitLimit if your repository is really large. > > ① automatic garbage collection, “git gc --aggressive --prune=now”, > and cloning are the use cases I have at hand right now. > > À propos, while here: is gc --aggressive safe to run on a live, > online-shared repository, or does it break other users accessing > the repository concurrently? (If it’s safe I’d very much like to do > that in a, say weekly, cronjob on FusionForge, our hosting system.) Running 'git gc' with --aggressive should be as safe as running it without --aggressive. But, you should think about whether you really need to run it more than once, or at all. When you use --aggressive, git will perform the entire delta search again for _every_ object in the repository. The general usecase for --aggressive is when you suspect that the original delta search produced sub-optimal deltas or if you modify the size of the delta search window or depth and want to regenerate your packed objects to improve compression or access speed. Even then, you will not likely get much benefit from running with --aggressive a second time. hth, -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