mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-09 02:33:11 +01:00
Code Activity
git/t/t5304-prune.sh

116 lines
2.6 KiB
Bash
Raw Normal View History

Make git prune remove temporary packs that look like write failures Write errors when repacking (eg, due to out-of-space conditions) can leave temporary packs (and possibly other files beginning with "tmp_") lying around which no existing codepath removes and which aren't obvious to the casual user. These can also be multi-megabyte files wasting noticeable space. Unfortunately there's no way to definitely tell in builtin-prune that a tmp_ file is not being used by a concurrent process, such as a fetch. However, it is documented that pruning should only be done on a quiet repository and --expire is honoured (using code from Johannes Schindelin, along with a test case he wrote) so that its safety is the same as that of loose object pruning. Since they might be signs of a problem (unlike orphaned loose objects) the names of any removed files are printed. Signed-off-by: David Tweed (david.tweed@gmail.com) Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 03:55:14 +01:00
#!/bin/sh
#
# Copyright (c) 2008 Johannes E. Schindelin
#
test_description='prune'
. ./test-lib.sh
test_expect_success setup '
: > file &&
git add file &&
test_tick &&
git commit -m initial &&
git gc
'
test_expect_success 'prune stale packs' '
orig_pack=$(echo .git/objects/pack/*.pack) &&
: > .git/objects/tmp_1.pack &&
: > .git/objects/tmp_2.pack &&
t5304-prune: adjust file mtime based on system time rather than file mtime test-chmtime can adjust the mtime of a file based on the file's mtime, or based on the system time. For files accessed over NFS, the file's mtime is set by the NFS server, and as such may vary a great deal from the NFS client's system time if the clocks of the client and server are out of sync. Since these tests are testing the expire feature of git-prune, an incorrect mtime could cause a file to be expired or not expired incorrectly and produce a test failure. Avoid this NFS pitfall by modifying the calls to test-chmtime so that the mtime is adjusted based on the system time, rather than the file's mtime. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-14 02:49:30 +02:00
test-chmtime =-86501 .git/objects/tmp_1.pack &&
Make git prune remove temporary packs that look like write failures Write errors when repacking (eg, due to out-of-space conditions) can leave temporary packs (and possibly other files beginning with "tmp_") lying around which no existing codepath removes and which aren't obvious to the casual user. These can also be multi-megabyte files wasting noticeable space. Unfortunately there's no way to definitely tell in builtin-prune that a tmp_ file is not being used by a concurrent process, such as a fetch. However, it is documented that pruning should only be done on a quiet repository and --expire is honoured (using code from Johannes Schindelin, along with a test case he wrote) so that its safety is the same as that of loose object pruning. Since they might be signs of a problem (unlike orphaned loose objects) the names of any removed files are printed. Signed-off-by: David Tweed (david.tweed@gmail.com) Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 03:55:14 +01:00
git prune --expire 1.day &&
test -f $orig_pack &&
test -f .git/objects/tmp_2.pack &&
! test -f .git/objects/tmp_1.pack
'
gc: call "prune --expire 2.weeks.ago" by default 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>
2008-03-12 21:55:47 +01:00
test_expect_success 'prune --expire' '
before=$(git count-objects | sed "s/ .*//") &&
BLOB=$(echo aleph | git hash-object -w --stdin) &&
BLOB_FILE=.git/objects/$(echo $BLOB | sed "s/^../&\//") &&
test $((1 + $before)) = $(git count-objects | sed "s/ .*//") &&
test -f $BLOB_FILE &&
git prune --expire=1.hour.ago &&
test $((1 + $before)) = $(git count-objects | sed "s/ .*//") &&
test -f $BLOB_FILE &&
t5304-prune: adjust file mtime based on system time rather than file mtime test-chmtime can adjust the mtime of a file based on the file's mtime, or based on the system time. For files accessed over NFS, the file's mtime is set by the NFS server, and as such may vary a great deal from the NFS client's system time if the clocks of the client and server are out of sync. Since these tests are testing the expire feature of git-prune, an incorrect mtime could cause a file to be expired or not expired incorrectly and produce a test failure. Avoid this NFS pitfall by modifying the calls to test-chmtime so that the mtime is adjusted based on the system time, rather than the file's mtime. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-14 02:49:30 +02:00
test-chmtime =-86500 $BLOB_FILE &&
gc: call "prune --expire 2.weeks.ago" by default 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>
2008-03-12 21:55:47 +01:00
git prune --expire 1.day &&
test $before = $(git count-objects | sed "s/ .*//") &&
! test -f $BLOB_FILE
'
test_expect_success 'gc: implicit prune --expire' '
before=$(git count-objects | sed "s/ .*//") &&
BLOB=$(echo aleph_0 | git hash-object -w --stdin) &&
BLOB_FILE=.git/objects/$(echo $BLOB | sed "s/^../&\//") &&
test $((1 + $before)) = $(git count-objects | sed "s/ .*//") &&
test -f $BLOB_FILE &&
t5304-prune: adjust file mtime based on system time rather than file mtime test-chmtime can adjust the mtime of a file based on the file's mtime, or based on the system time. For files accessed over NFS, the file's mtime is set by the NFS server, and as such may vary a great deal from the NFS client's system time if the clocks of the client and server are out of sync. Since these tests are testing the expire feature of git-prune, an incorrect mtime could cause a file to be expired or not expired incorrectly and produce a test failure. Avoid this NFS pitfall by modifying the calls to test-chmtime so that the mtime is adjusted based on the system time, rather than the file's mtime. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-14 02:49:30 +02:00
test-chmtime =-$((86400*14-30)) $BLOB_FILE &&
gc: call "prune --expire 2.weeks.ago" by default 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>
2008-03-12 21:55:47 +01:00
git gc &&
test $((1 + $before)) = $(git count-objects | sed "s/ .*//") &&
test -f $BLOB_FILE &&
t5304-prune: adjust file mtime based on system time rather than file mtime test-chmtime can adjust the mtime of a file based on the file's mtime, or based on the system time. For files accessed over NFS, the file's mtime is set by the NFS server, and as such may vary a great deal from the NFS client's system time if the clocks of the client and server are out of sync. Since these tests are testing the expire feature of git-prune, an incorrect mtime could cause a file to be expired or not expired incorrectly and produce a test failure. Avoid this NFS pitfall by modifying the calls to test-chmtime so that the mtime is adjusted based on the system time, rather than the file's mtime. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-14 02:49:30 +02:00
test-chmtime =-$((86400*14+1)) $BLOB_FILE &&
gc: call "prune --expire 2.weeks.ago" by default 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>
2008-03-12 21:55:47 +01:00
git gc &&
test $before = $(git count-objects | sed "s/ .*//") &&
! test -f $BLOB_FILE
'
test_expect_success 'gc: refuse to start with invalid gc.pruneExpire' '
git config gc.pruneExpire invalid &&
test_must_fail git gc
'
test_expect_success 'gc: start with ok gc.pruneExpire' '
git config gc.pruneExpire 2.days.ago &&
git gc
'
Add tests for git-prune It seems that git prune changed behaviour with respect to revisions added from command line, probably when it became a builtin. Currently, it prints a short usage and exits: instead, it should take those revisions into account and not prune them. So add a couple of test to point this out. We'll be fixing this by switching to parse_options(), so add tests to detect bogus command line parameters as well, to keep ourselves from introducing regressions. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-23 22:34:34 +01:00
test_expect_success 'prune: prune nonsense parameters' '
test_must_fail git prune garbage &&
test_must_fail git prune --- &&
test_must_fail git prune --no-such-option
'
test_expect_success 'prune: prune unreachable heads' '
git config core.logAllRefUpdates false &&
mv .git/logs .git/logs.old &&
: > file2 &&
git add file2 &&
git commit -m temporary &&
tmp_head=$(git rev-list -1 HEAD) &&
git reset HEAD^ &&
git prune &&
test_must_fail git reset $tmp_head --
'
builtin-prune: protect objects listed on the command line Finally, this resurrects the documented behaviour to protect other objects listed on the command line from getting pruned. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-25 07:20:51 +01:00
test_expect_success 'prune: do not prune heads listed as an argument' '
Add tests for git-prune It seems that git prune changed behaviour with respect to revisions added from command line, probably when it became a builtin. Currently, it prints a short usage and exits: instead, it should take those revisions into account and not prune them. So add a couple of test to point this out. We'll be fixing this by switching to parse_options(), so add tests to detect bogus command line parameters as well, to keep ourselves from introducing regressions. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-23 22:34:34 +01:00
: > file2 &&
git add file2 &&
git commit -m temporary &&
tmp_head=$(git rev-list -1 HEAD) &&
git reset HEAD^ &&
git prune -- $tmp_head &&
git reset $tmp_head --
'
Make git prune remove temporary packs that look like write failures Write errors when repacking (eg, due to out-of-space conditions) can leave temporary packs (and possibly other files beginning with "tmp_") lying around which no existing codepath removes and which aren't obvious to the casual user. These can also be multi-megabyte files wasting noticeable space. Unfortunately there's no way to definitely tell in builtin-prune that a tmp_ file is not being used by a concurrent process, such as a fetch. However, it is documented that pruning should only be done on a quiet repository and --expire is honoured (using code from Johannes Schindelin, along with a test case he wrote) so that its safety is the same as that of loose object pruning. Since they might be signs of a problem (unlike orphaned loose objects) the names of any removed files are printed. Signed-off-by: David Tweed (david.tweed@gmail.com) Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 03:55:14 +01:00
test_done
Copy permalink