aboutsummaryrefslogtreecommitdiff
path: root/builtin-gc.c
Commit message (Collapse)AuthorAge
* Merge branch 'js/config-cb'v1.5.6-rc0Junio C Hamano2008-05-25
|\ | | | | | | | | | | | | | | | | | | * js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
| * Provide git_config with a callback-data parameterJohannes Schindelin2008-05-14
| | | | | | | | | | | | | | | | | | | | | | | | git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | builtin-gc.c: deprecate --prune, it now really has no effectBrandon Casey2008-05-11
| |
* | git-gc: always use -A when manually repackingBrandon Casey2008-05-11
|/ | | | | | | | Now that repack -A will leave unreferenced objects unpacked, there is no reason to use the -a option to repack (which will discard unreferenced objects). The unpacked unreferenced objects will not be repacked by a subsequent repack, and will eventually be pruned by git-gc based on the gc.pruneExpire config option.
* git-gc --auto: add pre-auto-gc hookMiklos Vajna2008-04-09
| | | | | | | | If such a hook is available and exits with a non-zero status, then git-gc --auto won't run. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gc --auto: raise default auto pack limit from 20 to 50Junio C Hamano2008-03-23
| | | | | | | | | 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>
* builtin-gc.c: allow disabling all auto-gc'ing by assigning 0 to gc.autoBrandon Casey2008-03-19
| | | | | | | | | | | | | 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>
* gc: call "prune --expire 2.weeks.ago" by defaultJohannes Schindelin2008-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gc: Add --quiet optionFrank Lichtenheld2008-03-01
| | | | | | | Pass -q option to git-repack. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-gc.c: guard config parser from value=NULLMiklos Vajna2008-02-11
| | | | | Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* slightly better auto gc messageNicolas Pitre2008-01-07
| | | | | Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gc: --prune prunes unreferenced objects.Junio C Hamano2007-11-05
| | | | | | | | 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>
* gc: use parse_optionsJames Bowes2007-11-02
| | | | | Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-gc: improve wording of --auto notificationJeff King2007-10-18
| | | | | | | | | | | | 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>
* Add a message explaining that automatic GC is about to startkoreth@midwinter.com2007-10-18
| | | | | Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gc --auto: simplify "repack" command line buildingBrandon Casey2007-10-15
| | | | | | | | | | 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>
* git-gc: by default use safer "-A" option to repack when not --prune'ingBrandon Casey2007-10-15
| | | | | | | | | | | | | | 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>
* git-gc --auto: run "repack -A -d -l" as necessary.Junio C Hamano2007-09-17
| | | | | | | | | | | 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>
* git-gc --auto: restructure the way "repack" command line is built.Junio C Hamano2007-09-17
| | | | | | | | 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>
* git-gc --auto: protect ourselves from accumulated cruftJunio C Hamano2007-09-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>
* git-gc --auto: move threshold check to need_to_gc() function.Junio C Hamano2007-09-17
| | | | | | | That is where we decide if we are going to run gc automatically. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Implement git gc --autoJunio C Hamano2007-09-06
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make every builtin-*.c file #include "builtin.h"Peter Hagervall2007-07-14
| | | | | | | | | 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>
* Make "git gc" pack all refs by defaultLinus Torvalds2007-05-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add --aggressive option to 'git gc'Theodore Tso2007-05-10
| | | | | | | | | | | | 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>
* Make gc a builtin.James Bowes2007-03-17
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net>