summaryrefslogtreecommitdiff
path: root/t/t1410-reflog.sh
AgeCommit message (Collapse)AuthorFilesLines
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-4/+4
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28reflog: honor gc.reflogexpire=neverLibravatar Adam Simpkins1-0/+41
Previously, if gc.reflogexpire or gc.reflogexpire were set to "never" or "false", the builtin default values were used instead. Signed-off-by: Adam Simpkins <simpkins@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-19test-lib: Introduce test_chmod and use it instead of update-index --chmodLibravatar Johannes Sixt1-3/+1
This function replaces sequences of 'chmod +x' and 'git update-index --chmod=+x' in the test suite, whose purpose is to help filesystems that need core.filemode=false. Two places where only 'chmod +x' was used we also use this new function. The function calls 'git update-index --chmod' without checking core.filemode (unlike some of the call sites did). We do this because the call sites *expect* that the executable bit ends up in the index (ie. it is not the purpose of the call sites to *test* whether git treats 'chmod +x' and 'update-index --chmod=+x' correctly). Therefore, on filesystems with core.filemode=true the 'git update-index --chmod' is a no-op. The function uses --add with update-index to help one call site in t6031-merge-recursive. It makes no difference for the other callers. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2008-08-10Fix deleting reflog entries from HEAD reflogLibravatar Junio C Hamano1-1/+1
dwim_ref() used to resolve HEAD symbolic ref to its target (i.e. current branch). This incorrectly removed the reflog entry from the current branch when 'git reflog delete HEAD@{1}' was asked for. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-10reflog test: add more tests for 'reflog delete'Libravatar Pieter de Bie1-4/+18
This adds more tests for 'reflog delete' and marks it as broken, as currently a call to 'git reflog delete HEAD@{1}' deletes entries in the currently checked out branch's log, not the HEAD log. Noticed by John Wiegley Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-12gc: call "prune --expire 2.weeks.ago" by defaultLibravatar Johannes Schindelin1-18/+0
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-02-22Merge branch 'bc/reflog-fix' into js/reflog-deleteLibravatar Junio C Hamano1-0/+19
* bc/reflog-fix: (1490 commits) builtin-reflog.c: don't install new reflog on write failure hash: fix lookup_hash semantics gitweb: Better chopping in commit search results builtin-tag.c: remove cruft git-merge-index documentation: clarify synopsis send-email: fix In-Reply-To regression git-reset --hard and git-read-tree --reset: fix read_cache_unmerged() Teach git-grep --name-only as synonym for -l diff: fix java funcname pattern for solaris t3404: use configured shell instead of /bin/sh git_config_*: don't assume we are parsing a config file prefix_path: use is_absolute_path() instead of *orig == '/' git-clean: handle errors if removing files fails Clarified the meaning of git-add -u in the documentation git-clone.sh: properly configure remote even if remote's head is dangling git.el: Set process-environment instead of invoking env Documentation/git-stash: document options for git stash list send-email: squelch warning due to comparing undefined $_ to "" cvsexportcommit: be graceful when "cvs status" reorders the arguments Rename git-core rpm to just git and rename the meta-pacakge to git-all. ... Conflicts: Documentation/git-reflog.txt t/t1410-reflog.sh
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-10-17Teach "git reflog" a subcommand to delete single entriesLibravatar Johannes Schindelin1-0/+26
This commit implements the "delete" subcommand: git reflog delete master@{2} will delete the second reflog entry of the "master" branch. With this, it should be easy to implement "git stash pop" everybody seems to want these days. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>