summaryrefslogtreecommitdiff
path: root/t/t3600-rm.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-07-19Merge branch 'maint'Libravatar Junio C Hamano1-0/+12
* maint: GIT 1.5.6.4 builtin-rm: fix index lock file path http-fetch: do not SEGV after fetching a bad pack idx file rev-list: honor --quiet option api-run-command.txt: typofix
2008-07-19builtin-rm: fix index lock file pathLibravatar Olivier Marin1-0/+12
When hold_locked_index() is called with a relative git_dir and you are outside the work tree, the lock file become relative to the current directory. So when later setup_work_tree() change the current directory it breaks lock file path and commit_locked_index() fails. This patch move index locking code after setup_work_tree() call to make lock file relative to the working tree as it should be and add a test case. Noticed by Nick Andrew. Signed-off-by: Olivier Marin <dkr@freesurf.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-13/+13
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01Sane use of test_expect_failureLibravatar Junio C Hamano1-8/+9
Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-05t/t{3600,3800,5401}: do not use egrep when grep would doLibravatar Junio C Hamano1-1/+1
There is nothing _wrong_ with egrep per se, but this way we would have less dependency on external tools. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-13More permissive "git-rm --cached" behavior without -f.Libravatar Matthieu Moy1-0/+34
In the previous behavior, "git-rm --cached" (without -f) had the same restriction as "git-rm". This forced the user to use the -f flag in situations which weren't actually dangerous, like: $ git add foo # oops, I didn't want this $ git rm --cached foo # back to initial situation Previously, the index had to match the file *and* the HEAD. With --cached, the index must now match the file *or* the HEAD. The behavior without --cached is unchanged, but provides better error messages. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-24/+24
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-17Add --ignore-unmatch option to exit with zero status when no files are removed.Libravatar Steven Grimm1-0/+4
Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16Add --quiet option to suppress output of "rm" commands for removed files.Libravatar Steven Grimm1-0/+24
Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-25t3600: update the test for updated git rmLibravatar Junio C Hamano1-4/+74
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-29Remove unnecessary output from t3600-rm.Libravatar Shawn Pearce1-19/+23
Moved the setup commands into test_expect_success blocks so their output is hidden unless -v is used. This makes the test suite look a little cleaner when the rm test-file setup step fails (and was expected to fail for most cases). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-13t3600-rm: skip failed-remove test when we cannot make an unremovable file.Libravatar Junio C Hamano1-3/+15
When running t3600-rm test under fakeroot (or as root), we cannot make a file unremovable with "chmod a-w .". Detect this case early and skip that test. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-03workaround fat/ntfs deficiencies for t3600-rm.sh (git-rm)Libravatar Alex Riesen1-6/+17
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-22git-rm: Fix to properly handle files with spaces, tabs, newlines, etc.Libravatar Carl Worth1-17/+35
New tests are added to the git-rm test case to cover this as well. Signed-off-by: Carl Worth <cworth@cworth.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-22Add new git-rm command with documentationLibravatar Carl Worth1-0/+42
This adds a git-rm command which provides convenience similar to git-add, (and a bit more since it takes care of the rm as well if given -f). Like git-add, git-rm expands the given path names through git-ls-files. This means it only acts on files listed in the index. And it does act recursively on directories by default, (no -r needed as in the case of rm itself). When it recurses, it does not remove empty directories that are left behind. Signed-off-by: Junio C Hamano <junkio@cox.net>