() Samuel Bronson () Sat, 4 Jan 2014 02:14:04 +0000 (UTC) I'm given to understand that "git gc --aggressive" does not actually pack things more efficiently in practice, and is thus a waste of time, memory, *and* disk space. See [URL] IIUC, the criticism w/ "git gc --aggressive" is that it inhibits the normal incremental (reusing deltas) operation of the underlying repack, and thus counter-indicated for day-to-day (post init phase) use. Since i'm still in the init phase, "git gc --aggressive" is fine, in principle. (It's the practice, w/ old computer, that's the problem!) Also note Linus' suggestion to use "git repack" instead, perhaps with more aggressive options than the defaults. Yes, this did the trick. Some observations: First attempt -- 3h 10m, 1.5G $ git repack -a -d -f Second attempt -- 11h 55m, 559M $ git repack -a -d -f --window=250 --depth=250 --window-memory=200m Actually, i report only those attempts that completed. The others either died or i interrupted out of annoyance w/ swap-disk-grunting. 559M is not optimal, but i (and old computer :-D) can live w/ it. Next steps: - Sanity check. In the repo, i see HEAD is 6f7f591e (2013-12-07) w/ title (and entirety of commit message) "Mention bug 16049.". Could someone please confirm this exists in their git-bzr repo? - Investigate "no safeguard against rewriting upstream bzr repo history": . I'd like to determine if the "doesn't work" part lies in bzrlib or in git-remote-bzr. I suspect the latter, since there is no call to ‘die’ in that code. Hmmm, time to snapshot the (relatively) svelte repo and see what damage a tweaked git-remote-bzr can do, i suppose... "But ttn, why not just wait for Emacs to move to Git?" Well, i've waited many years and that was a suffering. Playing w/ git-bzr is another. Life is such. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) => nil