kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
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

15 Commits (6fa92bf3cdbfdd8c9c56ef40a5170a859442b166)