summaryrefslogtreecommitdiff
path: root/builtin-gc.c
AgeCommit message (Collapse)AuthorFilesLines
2008-03-01gc: Add --quiet optionLibravatar Frank Lichtenheld1-0/+4
Pass -q option to git-repack. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-11builtin-gc.c: guard config parser from value=NULLLibravatar Miklos Vajna1-1/+1
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-07slightly better auto gc messageLibravatar Nicolas Pitre1-1/+1
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05gc: --prune prunes unreferenced objects.Libravatar Junio C Hamano1-1/+1
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>
2007-11-02gc: use parse_optionsLibravatar James Bowes1-22/+22
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-18git-gc: improve wording of --auto notificationLibravatar Jeff King1-3/+3
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>
2007-10-18Add a message explaining that automatic GC is about to startLibravatar koreth@midwinter.com1-0/+4
Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15git-gc --auto: simplify "repack" command line buildingLibravatar Brandon Casey1-7/+1
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>
2007-10-15git-gc: by default use safer "-A" option to repack when not --prune'ingLibravatar Brandon Casey1-1/+11
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>
2007-09-17git-gc --auto: run "repack -A -d -l" as necessary.Libravatar Junio C Hamano1-6/+54
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>
2007-09-17git-gc --auto: restructure the way "repack" command line is built.Libravatar Junio C Hamano1-5/+10
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>
2007-09-17git-gc --auto: protect ourselves from accumulated cruftLibravatar Junio C Hamano1-8/+17
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>
2007-09-17git-gc --auto: move threshold check to need_to_gc() function.Libravatar Junio C Hamano1-2/+7
That is where we decide if we are going to run gc automatically. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06Implement git gc --autoLibravatar Junio C Hamano1-1/+63
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>
2007-07-14Make every builtin-*.c file #include "builtin.h"Libravatar Peter Hagervall1-0/+1
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>
2007-05-24Make "git gc" pack all refs by defaultLibravatar Linus Torvalds1-2/+2
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>
2007-05-10Add --aggressive option to 'git gc'Libravatar Theodore Tso1-2/+30
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>
2007-03-17Make gc a builtin.Libravatar James Bowes1-0/+78
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net>