2010-10-22 08:47:19 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='basic git gc tests
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
test_expect_success 'gc empty repository' '
|
|
|
|
|
git gc
|
|
|
|
|
'
|
|
|
|
|
|
gc: remove gc.pid file at end of execution
This file isn't really harmful, but isn't useful either, and can create
minor annoyance for the user:
* It's confusing, as the presence of a *.pid file often implies that a
process is currently running. A user running "ls .git/" and finding
this file may incorrectly guess that a "git gc" is currently running.
* Leaving this file means that a "git gc" in an already gc-ed repo is
no-longer a no-op. A user running "git gc" in a set of repositories,
and then synchronizing this set (e.g. rsync -av, unison, ...) will see
all the gc.pid files as changed, which creates useless noise.
This patch unlinks the file after the garbage collection is done, so that
gc.pid is actually present only during execution.
Future versions of Git may want to use the information left in the gc.pid
file (e.g. for policies like "don't attempt to run a gc if one has
already been ran less than X hours ago"). If so, this patch can safely be
reverted. For now, let's not bother the users.
Explained-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-17 01:11:46 +02:00
|
|
|
test_expect_success 'gc does not leave behind pid file' '
|
|
|
|
|
git gc &&
|
|
|
|
|
test_path_is_missing .git/gc.pid
|
|
|
|
|
'
|
|
|
|
|
|
2010-10-22 08:47:19 +02:00
|
|
|
test_expect_success 'gc --gobbledegook' '
|
|
|
|
|
test_expect_code 129 git gc --nonsense 2>err &&
|
2012-08-27 07:36:55 +02:00
|
|
|
test_i18ngrep "[Uu]sage: git gc" err
|
2010-10-22 08:47:19 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'gc -h with invalid configuration' '
|
|
|
|
|
mkdir broken &&
|
|
|
|
|
(
|
|
|
|
|
cd broken &&
|
|
|
|
|
git init &&
|
|
|
|
|
echo "[gc] pruneexpire = CORRUPT" >>.git/config &&
|
|
|
|
|
test_expect_code 129 git gc -h >usage 2>&1
|
|
|
|
|
) &&
|
2012-08-27 07:36:55 +02:00
|
|
|
test_i18ngrep "[Uu]sage" broken/usage
|
2010-10-22 08:47:19 +02:00
|
|
|
'
|
|
|
|
|
|
2015-09-28 16:01:25 +02:00
|
|
|
test_expect_success 'gc is not aborted due to a stale symref' '
|
2015-09-28 16:01:13 +02:00
|
|
|
git init remote &&
|
|
|
|
|
(
|
|
|
|
|
cd remote &&
|
|
|
|
|
test_commit initial &&
|
|
|
|
|
git clone . ../client &&
|
|
|
|
|
git branch -m develop &&
|
|
|
|
|
cd ../client &&
|
|
|
|
|
git fetch --prune &&
|
|
|
|
|
git gc
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2016-12-28 23:45:41 +01:00
|
|
|
test_expect_success 'auto gc with too many loose objects does not attempt to create bitmaps' '
|
|
|
|
|
test_config gc.auto 3 &&
|
|
|
|
|
test_config gc.autodetach false &&
|
|
|
|
|
test_config pack.writebitmaps true &&
|
|
|
|
|
# We need to create two object whose sha1s start with 17
|
|
|
|
|
# since this is what git gc counts. As it happens, these
|
|
|
|
|
# two blobs will do so.
|
|
|
|
|
test_commit 263 &&
|
|
|
|
|
test_commit 410 &&
|
|
|
|
|
# Our first gc will create a pack; our second will create a second pack
|
|
|
|
|
git gc --auto &&
|
|
|
|
|
ls .git/objects/pack | sort >existing_packs &&
|
|
|
|
|
test_commit 523 &&
|
|
|
|
|
test_commit 790 &&
|
|
|
|
|
|
|
|
|
|
git gc --auto 2>err &&
|
|
|
|
|
test_i18ngrep ! "^warning:" err &&
|
|
|
|
|
ls .git/objects/pack/ | sort >post_packs &&
|
|
|
|
|
comm -1 -3 existing_packs post_packs >new &&
|
|
|
|
|
comm -2 -3 existing_packs post_packs >del &&
|
|
|
|
|
test_line_count = 0 del && # No packs are deleted
|
|
|
|
|
test_line_count = 2 new # There is one new pack and its .idx
|
|
|
|
|
'
|
|
|
|
|
|
gc: ignore old gc.log files
A server can end up in a state where there are lots of unreferenced
loose objects (say, because many users are doing a bunch of rebasing
and pushing their rebased branches). Running "git gc --auto" in
this state would cause a gc.log file to be created, preventing
future auto gcs, causing pack files to pile up. Since many git
operations are O(n) in the number of pack files, this would lead to
poor performance.
Git should never get itself into a state where it refuses to do any
maintenance, just because at some point some piece of the maintenance
didn't make progress.
Teach Git to ignore gc.log files which are older than (by default)
one day old, which can be tweaked via the gc.logExpiry configuration
variable. That way, these pack files will get cleaned up, if
necessary, at least once per day. And operators who find a need for
more-frequent gcs can adjust gc.logExpiry to meet their needs.
There is also some cleanup: a successful manual gc, or a
warning-free auto gc with an old log file, will remove any old
gc.log files.
It might still happen that manual intervention is required
(e.g. because the repo is corrupt), but at the very least it won't
be because Git is too dumb to try again.
Signed-off-by: David Turner <dturner@twosigma.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-10 22:28:22 +01:00
|
|
|
test_expect_success 'background auto gc does not run if gc.log is present and recent but does if it is old' '
|
|
|
|
|
test_commit foo &&
|
|
|
|
|
test_commit bar &&
|
|
|
|
|
git repack &&
|
|
|
|
|
test_config gc.autopacklimit 1 &&
|
|
|
|
|
test_config gc.autodetach true &&
|
|
|
|
|
echo fleem >.git/gc.log &&
|
|
|
|
|
test_must_fail git gc --auto 2>err &&
|
|
|
|
|
test_i18ngrep "^error:" err &&
|
|
|
|
|
test_config gc.logexpiry 5.days &&
|
|
|
|
|
test-chmtime =-345600 .git/gc.log &&
|
|
|
|
|
test_must_fail git gc --auto &&
|
|
|
|
|
test_config gc.logexpiry 2.days &&
|
|
|
|
|
git gc --auto
|
|
|
|
|
'
|
2016-12-28 23:45:41 +01:00
|
|
|
|
2010-10-22 08:47:19 +02:00
|
|
|
test_done
|