From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Natter Subject: Re: git repack vs git gc --aggressive Date: Fri, 10 Aug 2012 21:09:38 +0200 Message-ID: <87ehnewolp.fsf@bitburger.home.felix> References: <87zk66r28y.fsf@bitburger.home.felix> <20120807184405.GA440@sigill.intra.peff.net> <7vvcguv7y2.fsf@alter.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Fri Aug 10 21:12:16 2012 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Szucd-0004gZ-Fj for gcvg-git-2@plane.gmane.org; Fri, 10 Aug 2012 21:11:47 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759805Ab2HJTLn (ORCPT ); Fri, 10 Aug 2012 15:11:43 -0400 Received: from plane.gmane.org ([80.91.229.3]:34368 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759915Ab2HJTLi (ORCPT ); Fri, 10 Aug 2012 15:11:38 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Szuat-0000sg-Sf for git@vger.kernel.org; Fri, 10 Aug 2012 21:09:59 +0200 Received: from pd9e84b14.dip.t-dialin.net ([217.232.75.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Aug 2012 21:09:59 +0200 Received: from fnatter by pd9e84b14.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Aug 2012 21:09:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pd9e84b14.dip.t-dialin.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Cancel-Lock: sha1:xScRWNs2yr+j0FcWvNXPEC9kFBA= Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Junio C Hamano writes: > Jeff King writes: > >> So the packing parameters are the same these days for either method. >> Note that "git gc --aggressive" will also use "-f" to recompute all >> deltas. This is more expensive, but gives git more flexibility if the >> old deltas were sub-optimal (typically, this is the case if the existing >> pack was generated by fast-import, which favors speed of import versus >> coming up with an optimal storage pattern). > > Also your fetch often results in storing the pack received from the > other end straight to your local repository (with necessary objects > to complete the pack the other end did not send appended at the > end). If the server side hasn't been packed with "-f", you will > inherit the badness until you repack with "-f". > >> Of course, every workload is different. One can develop pathological >> cases where --depth=500 saves a lot of space. But it's unlikely that it >> is the case for a normal repository. You can always try both and see the >> result. > > For a dataset where ridiculously large depth really is a win, these > objects would have to be reasonably large and cost of expanding the > base and then applying hundreds of delta to recover one object may > not be negligible. The user should consider if he is willing to pay > the price every time he does a local Git operation. > >> In fact, I'd also test how just "git gc" behaves versus "git gc >> --aggressive" for your repo. The former is much less expensive to run. >> You really shouldn't need to be running "--aggressive" all the time, so >> if you are looking at doing a nightly repack or similar, just "git gc" >> is probably fine. Thank you both very much for your answers! I have a few questions about this: > As I am coming from "large depth is harmful" school, I would > recommend > > - "git repack -a -d -f" with large "--window" with reasonably short > "--depth" once, So something like --depth=250 and --window=500? > and mark the result with .keep; I guess you refer to a toplevel '.keep' file. But what does that do (sorry, couldn't find anything on google)? > - "git repack -a -d -f" once every several weeks; and > > - "git gc" or "git repack" (without any other options) daily. > > and ignore "--aggressive" entirely. One more question: I use bzr fast-export | git fast-import to import branches from bzr: bzr fast-export --marks=$MARKS_BZR --git-branch="$BRANCHNAME" "$BZR_FREEPLANE_REPO/$BRANCHNAME/" | \ git fast-import --import-marks=$MARKS_GIT --export-marks=$MARKS_GIT Will those marks files (which remember which commits are already there in the git repo) also work after I have done git repack / git gc? In other words, can I import bzr-branches after I have run git repack / git gc on the repo? Thank you! -- Felix Natter