From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Move to git is imminent - awaiting Stefan's approval Date: Wed, 08 Jan 2014 17:23:58 +0200 Message-ID: <83eh4ifqep.fsf@gnu.org> References: <52CB2AB0.4080505@alice.it> <877gachfza.fsf@igel.home> <52CBD5CC.4020804@alice.it> <8761pvvoq1.fsf@rosalinde.fritz.box> <83d2k3sqqz.fsf@gnu.org> <52CC2D45.1000908@alice.it> <83a9f7sosr.fsf@gnu.org> <87siszhfil.fsf@uwakimon.sk.tsukuba.ac.jp> <834n5fsm4y.fsf@gnu.org> <87ob3nhbkb.fsf@uwakimon.sk.tsukuba.ac.jp> <83y52rr4q4.fsf@gnu.org> <87k3ebgmni.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389194665 5073 80.91.229.3 (8 Jan 2014 15:24:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 15:24:25 +0000 (UTC) Cc: schwab@suse.de, stephen.berman@gmx.net, sven.axelsson@gmail.com, angelo.graziosi@alice.it, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 08 16:24:32 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 1W0uze-0007Pu-4I for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 16:24:30 +0100 Original-Received: from localhost ([::1]:47396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0uzd-0002fS-JE for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 10:24:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0uzW-0002Yf-JS for emacs-devel@gnu.org; Wed, 08 Jan 2014 10:24:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0uzP-0005hp-GP for emacs-devel@gnu.org; Wed, 08 Jan 2014 10:24:22 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:62431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0uzP-0005hg-2u for emacs-devel@gnu.org; Wed, 08 Jan 2014 10:24:15 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MZ300J00969QJ00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Wed, 08 Jan 2014 17:24:04 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ300JHZ9G3LJ50@a-mtaout20.012.net.il>; Wed, 08 Jan 2014 17:24:04 +0200 (IST) In-reply-to: <87k3ebgmni.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:167733 Archived-At: > From: "Stephen J. Turnbull" > Cc: schwab@suse.de, > stephen.berman@gmx.net, > emacs-devel@gnu.org, > sven.axelsson@gmail.com, > angelo.graziosi@alice.it > Date: Wed, 08 Jan 2014 12:47:29 +0900 > > Eli Zaretskii writes: > > I did read the documentation. The docs of gc mentions git-repack, so > > I thought the former runs the latter. What part did I miss? > > The fact that the documentation clearly puts conditions on when git-gc > runs git-repack. I wouldn't qualify the gc manpage as "clear" on this matter, see below. But given what it does say, I _guessed_ that "git gc" _might_ run git-repack, and asked whether that wasn't so. Why that pissed you off I don't know. You seem to have deduced a different conclusion, but IMO that's just one more evidence that the man page is not really clear on this matter. > > And how was I supposed to know from this whether git-repack will or > > won't be run, what with the word "repack" explicitly in this text (and > > in other parts of that man page)? > > Huh? If there's a condition on whether it runs, then presumably > sometimes it doesn't run. AFAIU, you refer to this part of your previous message: > Specifically, according to the help, git-gc removes garbage (in the > usual sense of a tracing collector) and "compresses" (ie, packs) loose > objects using delta compression (and then the result is deflated as > with loose objects, I believe). It will repack the packs into *one* > pack (presumably with better delta compression) if the number of packs > is greater than the value of gc.autopacklimit (in .git/config; > default: 50). However, this comes from the part in the man page that describes the "--auto" option to gc. I didn't use and didn't mean to use that option, so the above is not necessarily relevant to "git gc". But even if this description is relevant when --auto is not used, the above says that repacking will sometimes happen. As to what happens regardless of any options, the man page says just this: DESCRIPTION Runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase performance) and removing unreachable objects which may have been created from prior invocations of git add. This says "such as", which doesn't imply an exhaustive list of tasks. Moreover, it never says that "compressing file revisions" and "removing unreachable objects" is not done by git-repack. So the above description does not contradict my conclusion, and definitely doesn't present exact description of the conditions under which gc will run repack. Perhaps if I knew exactly what repack does, I could have filled the voids, but I don't. Finally, the "Configuration" section has this, among the rest: The optional configuration variable gc.packrefs determines if git gc runs git pack-refs. This can be set to "notbare" to enable it within all non-bare repos or it can be set to a boolean value. This defaults to true. The optional configuration variable gc.aggressiveWindow controls how much time is spent optimizing the delta compression of the objects in the repository when the --aggressive option is specified. The larger the value, the more time is spent optimizing the delta compression. See the documentation for the --window' option in git-repack(1) for more details. This defaults to 250. Both of these configuration settings explicitly mention packing and/or repacking. Again, without knowing exactly what repack does, there's no clarity here whether pack-refs is related to repack in any way, shape or form (looking in the sources resolves this, see below). Given these hints, IMO it was a reasonable guess that gc does run repack at least under some conditions, when --auto is not used. Since these conditions are not defined completely by the man page, it was my guess that gc, with or without the --aggressive option, might run repack. As it turns out, the second part is surely true. > You read the source? I find that hard to believe. I didn't read the source in this case, only the documentation. I don't understand the "hard to believe" part, though: I do have the git's git repo on my disk, and you could easily imagine that I'm not new to reading sources. Having now looked in the sources, this is what I see: if (pack_refs && run_command_v_opt(pack_refs_cmd.argv, RUN_GIT_CMD)) return error(FAILED_RUN, pack_refs_cmd.argv[0]); if (run_command_v_opt(reflog.argv, RUN_GIT_CMD)) return error(FAILED_RUN, reflog.argv[0]); if (run_command_v_opt(repack.argv, RUN_GIT_CMD)) return error(FAILED_RUN, repack.argv[0]); if (prune_expire) { argv_array_push(&prune, prune_expire); if (quiet) argv_array_push(&prune, "--no-progress"); if (run_command_v_opt(prune.argv, RUN_GIT_CMD)) return error(FAILED_RUN, prune.argv[0]); } if (run_command_v_opt(rerere.argv, RUN_GIT_CMD)) return error(FAILED_RUN, rerere.argv[0]); My reading of this is that "git gc" runs, in sequence, pack-refs (conditioned on gc.packrefs), reflog, repack, prune (conditioned on the --prune option), and finally rerere. IOW, "git gc" does run repack. The only difference between --aggressive and non-aggressive modes is here: if (aggressive) { argv_array_push(&repack, "-f"); argv_array_push(&repack, "--depth=250"); if (aggressive_window > 0) argv_array_pushf(&repack, "--window=%d", aggressive_window); } That is, --aggressive just passes the -f switch to git-repack, which tells it not to reuse deltas (i.e. recompute them anew, AFAIU). > (The doc for --aggressive says nothing about repack, only that it > optimizes harder.) See above: the description of aggressiveWindow setting quite clearly says that --aggressive does run repack. And in fact it does, indeed. > > Stephen can now be pissed off by himself. > > Yup. And I won't waste time on suppressing my irritation while > helping with GitForEmacsDevs Too bad.