Граф коммитов

15 Коммитов

Автор SHA1 Сообщение Дата
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>
2007-11-05 16:39:00 -08:00
James Bowes 44c637c802 gc: use parse_options
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02 01:31:06 -07:00
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>
2007-10-18 22:23:50 -04:00
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>
2007-10-18 01:10:56 -04:00
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>
2007-10-15 20:50:05 -04:00
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>
2007-10-15 20:50:05 -04:00
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>
2007-09-17 23:12:16 -07:00
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>
2007-09-17 23:12:15 -07:00
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>
2007-09-17 23:12:15 -07:00
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>
2007-09-17 23:12:15 -07:00
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>
2007-09-06 00:08:56 -07:00
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>
2007-07-14 22:44:09 -07:00
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>
2007-05-24 19:05:39 -07:00
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>
2007-05-10 15:24:40 -07:00
James Bowes 6757ada403 Make gc a builtin.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-17 00:34:19 -07:00