summaryrefslogtreecommitdiff
path: root/t/t1410-reflog.sh
AgeCommit message (Collapse)AuthorFilesLines
2007-11-30Add "--expire <time>" option to 'git prune'Libravatar Johannes Schindelin1-0/+18
Earlier, 'git prune' would prune all loose unreachable objects. This could be quite dangerous, as the objects could be used in an ongoing operation. This patch adds a mode to expire only loose, unreachable objects which are older than a certain time. For example, by git prune --expire 14.days you can prune only those objects which are loose, unreachable and older than 14 days (and thus probably outdated). The implementation uses st.st_mtime rather than st.st_ctime, because it can be tested better, using 'touch -d <time>' (and omitting the test when the platform does not support that command line switch). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-01-28git-fsck-objects is now synonym to git-fsckLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-1/+1
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-21Revert "prune: --grace=time"Libravatar Junio C Hamano1-3/+3
This reverts commit 9b088c4e394df84232cfd37aea78349a495b09c1. Protecting 'mature' objects does not make it any safer. We should admit that git-prune is inherently unsafe when run in parallel with other operations without involving unwarranted locking overhead, and with the latest git, even rebase and reset would not immediately create crufts anyway.
2007-01-20prune: --grace=timeLibravatar Matthias Lederhofer1-3/+3
This option gives grace period to objects that are unreachable from the refs from getting pruned. The default value is 24 hours and may be changed using gc.prunegrace. Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10Fix t1410 for core.filemode==falseLibravatar Johannes Schindelin1-0/+2
Since c869753e, core.filemode is hardwired to false on Cygwin. So this test had no chance to succeed, since an early commit (changing just the filemode) failed, and therefore all subsequent tests. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-06reflog expire --fix-staleLibravatar Junio C Hamano1-0/+176
The logic in an earlier round to detect reflog entries that point at a broken commit was not sufficient. Just like we do not trust presense of a commit during pack transfer (we trust only our refs), we should not trust a commit's presense, even if the tree of that commit is complete. A repository that had reflog enabled on some of the refs that was rewound and then run git-repack or git-prune from older versions of git can have reflog entries that point at a commit that still exist but lack commits (or trees and blobs needed for that commit) between it and some commit that is reachable from one of the refs. This revamps the logic -- the definition of "broken commit" becomes: a commit that is not reachable from any of the refs and there is a missing object among the commit, tree, or blob objects reachable from it that is not reachable from any of the refs. Entries in the reflog that refer to such a commit are expired. Since this computation involves traversing all the reachable objects, i.e. it has the same cost as 'git prune', it is enabled only when a new option --fix-stale. Fortunately, once this is run, we should not have to ever worry about missing objects, because the current prune and pack-objects know about reflogs and protect objects referred by them. Unfortunately, this will be absolutely necessary to help people migrate to the newer prune and repack. Signed-off-by: Junio C Hamano <junkio@cox.net>