kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	970639740c	gc --auto: raise default auto pack limit from 20 to 50 Recent discussion on the list, with the improvement `f7c22cc` (always start looking up objects in the last used pack first, 2007-05-30) brought in, reached the concensus that the current default 20 is too low. Reference: http://thread.gmane.org/gmane.comp.version-control.git/77586 Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Brandon Casey	b14d255ba8	builtin-gc.c: allow disabling all auto-gc'ing by assigning 0 to gc.auto The gc.auto configuration variable is somewhat ambiguous now that there is also a gc.autopacklimit setting. Some users may assume that it controls all auto-gc'ing. Also, now users must set two configuration variables to zero when they want to disable autopacking. Since it is unlikely that users will want to autopack based on some threshold of pack files when they have disabled autopacking based on the number of loose objects, be nice and allow a setting of zero for gc.auto to disable all autopacking. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Schindelin	25ee9731c1	gc: call "prune --expire 2.weeks.ago" by default The only reason we did not call "prune" in git-gc was that it is an inherently dangerous operation: if there is a commit going on, you will prune loose objects that were just created, and are, in fact, needed by the commit object just about to be created. Since it is dangerous, we told users so. That led to many users not even daring to run it when it was actually safe. Besides, they are users, and should not have to remember such details as when to call git-gc with --prune, or to call git-prune directly. Of course, the consequence was that "git gc --auto" gets triggered much more often than we would like, since unreferenced loose objects (such as left-overs from a rebase or a reset --hard) were never pruned. Alas, git-prune recently learnt the option --expire <minimum-age>, which makes it a much safer operation. This allows us to call prune from git-gc, with a grace period of 2 weeks for the unreferenced loose objects (this value was determined in a discussion on the git list as a safe one). If you want to override this grace period, just set the config variable gc.pruneExpire to a different value; an example would be [gc] pruneExpire = 6.months.ago or even "never", if you feel really paranoid. Note that this new behaviour makes "--prune" be a no-op. While adding a test to t5304-prune.sh (since it really tests the implicit call to "prune"), also the original test for "prune --expire" was moved there from t1410-reflog.sh, where it did not belong. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>	17 years ago
Frank Lichtenheld	a0c14cbb2e	gc: Add --quiet option Pass -q option to git-repack. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Miklos Vajna	c5e5a2c097	builtin-gc.c: guard config parser from value=NULL Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Nicolas Pitre	7ec43959f7	slightly better auto gc message Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	0aab4abdd4	gc: --prune prunes unreferenced objects. Brandon Casey correctly points out that we repack with -A without --prune and with -a with --prune, so it is not just unreferenced loose objects that are pruned away when the option is given. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
James Bowes	44c637c802	gc: use parse_options Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jeff King	dd8b883ab9	git-gc: improve wording of --auto notification The previous message had too much of a "boy, you should really turn off this annoying gc" flair to it. Instead, let's make sure the user understands what is happening, that they can run it themselves, and where to find more info. Suggested by Brian Gernhardt. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
koreth@midwinter.com	130faabe48	Add a message explaining that automatic GC is about to start Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Brandon Casey	729f50453c	git-gc --auto: simplify "repack" command line building Since "-a" is removed from the base repack command line, we can simplify how we add additional options to this command line when using --auto. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Brandon Casey	edb0e04e81	git-gc: by default use safer "-A" option to repack when not --prune'ing This makes use of repack's new "-A" option which does not drop packed unreachable objects. This makes git-gc safe to call at any time, particularly when a repository is referenced as an alternate by another repository. git-gc --prune will use the "-a" option to repack instead of "-A", so that packed unreachable objects will be removed. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Junio C Hamano	17815501a8	git-gc --auto: run "repack -A -d -l" as necessary. This teaches "git-gc --auto" to consolidate many packs into one without losing unreachable objects in them by using "repack -A" when there are too many packfiles that are not marked with *.keep in the repository. gc.autopacklimit configuration can be used to set the maximum number of packs a repository is allowed to have before this mechanism kicks in. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	95143f9e68	git-gc --auto: restructure the way "repack" command line is built. We used to build the command line to run repack outside of need_to_gc() but with the next patch we would want to tweak the command line depending on the nature of need. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	a087cc9819	git-gc --auto: protect ourselves from accumulated cruft Deciding to run "repack -d -l" when there are too many loose objects would backfire when there are too many loose objects that are unreachable, because repacking that way would never improve the situation. Detect that case by checking the number of loose objects again after automatic garbage collection runs, and issue an warning to run "prune" manually. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	caf9de2f46	git-gc --auto: move threshold check to need_to_gc() function. That is where we decide if we are going to run gc automatically. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	2c3c439947	Implement git gc --auto This implements a new option "git gc --auto". When gc.auto is set to a positive value, and the object database has accumulated roughly that many number of loose objects, this runs a lightweight version of "git gc". The primary difference from the full "git gc" is that it does not pass "-a" option to "git repack", which means we do not try to repack _everything_, but only repack incrementally. We still do "git prune-packed". The default threshold is arbitrarily set by yours truly to: - not trigger it for fully unpacked git v0.99 history; - do trigger it for fully unpacked git v1.0.0 history; - not trigger it for incremental update to git v1.0.0 starting from fully packed git v0.99 history. This patch does not add invocation of the "auto repacking". It is left to key Porcelain commands that could produce tons of loose objects to add a call to "git gc --auto" after they are done their work. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Peter Hagervall	baffc0e770	Make every builtin-.c file #include "builtin.h" Make every builtin-.c file #include "builtin.h". Also takes care of some declaration/definition mismatches. Signed-off-by: Peter Hagervall <hager@cs.umu.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Linus Torvalds	56752391a8	Make "git gc" pack all refs by default I've taught myself to use "git gc" instead of doing the repack explicitly, but it doesn't actually do what I think it should do. We've had packed refs for a long time now, and I think it just makes sense to pack normal branches too. So I end up having to do git pack-refs --all --prune in order to get a nice git repo that doesn't have any unnecessary files. So why not just do that in "git gc"? It's not as if there really is any downside to packing branches, even if they end up changing later. Quite often they don't, and even if they do, so what? Also, make the default for refs packing just be an unambiguous "do it", rather than "do it by default only for non-bare repositories". If you want that behaviour, you can always just add a [gc] packrefs = notbare in your ~/.gitconfig file, but I don't actually see why bare would be any different (except for the broken reason that http-fetching used to be totally broken, and not doing it just meant that it didn't even get fixed in a timely manner!). So here's a trivial patch to make "git gc" do a better job. Hmm? Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Theodore Tso	0d7566a5ba	Add --aggressive option to 'git gc' This option causes 'git gc' to more aggressively optimize the repository at the cost of taking much more wall clock and CPU time. Today this option causes git-pack-objects to use --no-use-delta option, and it allows the --window parameter to be set via the gc.aggressiveWindow configuration parameter. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
James Bowes	6757ada403	Make gc a builtin. Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago

21 Commits (f53423b0e09d0de9584f72ac298bdfdc9e886d73)