From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: bzr is dying; Emacs needs to move Date: Sun, 05 Jan 2014 08:11:28 +0100 Message-ID: <87a9faq4wv.fsf@zigzag.favinet> References: <20140102095347.6834E381D0C@snark.thyrsus.com> <87k3eisirv.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1388905684 2577 80.91.229.3 (5 Jan 2014 07:08:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Jan 2014 07:08:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Samuel Bronson Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 05 08:08:09 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vzhof-0003l9-3A for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 08:08:09 +0100 Original-Received: from localhost ([::1]:56847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzhoe-0004Nl-L6 for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 02:08:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzhoX-0004NT-02 for emacs-devel@gnu.org; Sun, 05 Jan 2014 02:08:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzhoR-0007MI-15 for emacs-devel@gnu.org; Sun, 05 Jan 2014 02:08:00 -0500 Original-Received: from smtp206.alice.it ([82.57.200.102]:26196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzhoQ-0007M5-Ms for emacs-devel@gnu.org; Sun, 05 Jan 2014 02:07:54 -0500 Original-Received: from zigzag.favinet (79.1.74.217) by smtp206.alice.it (8.6.060.28) id 529A678F0739E913; Sun, 5 Jan 2014 08:07:52 +0100 Original-Received: from ttn by zigzag.favinet with local (Exim 4.80) (envelope-from ) id 1Vzhs5-0001nF-QA; Sun, 05 Jan 2014 08:11:41 +0100 Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: (Samuel Bronson's message of "Sat, 4 Jan 2014 02:14:04 +0000 (UTC)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.102 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167347 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () 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=3D250 --depth=3D250 --window-memory=3D200m 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: =2D 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? =2D 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 =E2=80=98die=E2=80=99 in that code. Hmmm, time to snapshot the (relat= ively) 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. =2D-=20 Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) =3D> nil --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLJBaUACgkQZwMiJEyAdQLCygCaAzekV8fVPYqaz/KFRzojo4Ct /JQAn28G5moER6EQbSGM4WD6a/UkMlWM =Ve7j -----END PGP SIGNATURE----- --=-=-=--