aboutsummaryrefslogtreecommitdiff
path: root/t/t3600-rm.sh
Commit message (Collapse)AuthorAge
* Merge branch 'jc/fix-diff-files-unmerged'Junio C Hamano2011-05-06
|\ | | | | | | | | | | | | | | * jc/fix-diff-files-unmerged: diff-files: show unmerged entries correctly diff: remove often unused parameters from diff_unmerge() diff.c: return filepair from diff_unmerge() test: use $_z40 from test-lib
| * test: use $_z40 from test-libJunio C Hamano2011-04-23
| | | | | | | | | | | | | | There is no need to duplicate the definition of $_z40 and $_x40 that test-lib.sh supplies the test scripts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t3600-rm.sh: Don't pass a non-existent prereq to test #15Ramsay Jones2010-12-14
|/ | | | | | | | | | | | | Commit c91cfd19 (tests: A SANITY test prereq for testing if we're root, 2010-08-06) introduced a SANITY prerequisite which had very similar semantics to RO_DIR. That commit removed the code to set RO_DIR, but forgot to replace RO_DIR with SANITY in test #15. In order not to skip test 15 unnecessarily, since RO_DIR will never be set, we pass the SANITY prerequisite instead. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tests: A SANITY test prereq for testing if we're rootÆvar Arnfjörð Bjarmason2010-08-18
| | | | | | | | | | | | | | | | | | | | | Some tests depend on not being able to write to files after chmod -w. This doesn't work when running the tests as root. Change test-lib.sh to test if this works, and if so it sets a new SANITY test prerequisite. The tests that use this previously failed when run under root. There was already a test for this in t3600-rm.sh, added by Junio C Hamano in 2283645 in 2006. That check now uses the new SANITY prerequisite. Some of this was resurrected from the "Tests in Cygwin" thread in May 2009: http://thread.gmane.org/gmane.comp.version-control.git/116729/focus=118385 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tests: Skip tests in a way that makes sense under TAPÆvar Arnfjörð Bjarmason2010-06-25
| | | | | | | | | | SKIP messages are now part of the TAP plan. A TAP harness now knows why a particular test was skipped and can report that information. The non-TAP harness built into Git's test-lib did nothing special with these messages, and is unaffected by these changes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rm: fix bug in recursive subdirectory removalJeff King2010-02-18
| | | | | | | | | | | | | | If we remove a path in a/deep/subdirectory, we should try to remove as many trailing components as possible (i.e., subdirectory, then deep, then a). However, the test for the return value of rmdir was reversed, so we only ever deleted at most one level. The fix is in remove_path, so "apply" and "merge-recursive" also are fixed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t3600: Use test prerequisite tagsJohannes Sixt2009-03-22
| | | | | | | | | | | | | | There are two prerequisites: - The filesystem supports names with tabs or new-lines. - Files cannot be removed if their containing directory is read-only. Previously, whether these preconditions are satisified was tested inside test_expect_success. We move these tests outside because, strictly speaking, they are not part of the tests. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* Call 'say' outside test_expect_successJohannes Sixt2009-03-19
| | | | | | | | There were some uses of 'say' inside test_expect_success. But if the tests were not run in verbose mode, this message went to /dev/null. Pull them out of test_expect_success. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* test suite: Use 'say' to say something instead of 'test_expect_success'Johannes Sixt2009-03-19
| | | | | | | | | | | Some tests report that some tests will be skipped. They used 'test_expect_success' with a trivially successful test. Nowadays we have the helper function 'say' for this purpose. In on case, 'say_color skip' is replaced by 'say' because the former is not intended as a public API. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* Make sure lockfiles are unlocked when dying on SIGPIPEJunio C Hamano2008-12-21
| | | | | | | | | We cleaned up lockfiles upon receiving the usual suspects HUP, TERM, QUIT but a wicked user could kill us of asphyxiation by piping our output to a pipe that does not read. Protect ourselves by catching SIGPIPE and clean up the lockfiles as well in such a case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git add --intent-to-add: fix removal of cached emptinessJunio C Hamano2008-11-28
| | | | | | | | | | | | | | | | | | This uses the extended index flag mechanism introduced earlier to mark the entries added to the index via "git add -N" with CE_INTENT_TO_ADD. The logic to detect an "intent to add" entry for the purpose of allowing "git rm --cached $path" is tightened to check not just for a staged empty blob, but with the CE_INTENT_TO_ADD bit. This protects an empty blob that was explicitly added and then modified in the work tree from being dropped with this sequence: $ >empty $ git add empty $ echo "non empty" >empty $ git rm --cached empty Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rm: loosen safety valve for empty filesJeff King2008-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a file is different between the working tree copy, the index, and the HEAD, then we do not allow it to be deleted without --force. However, this is overly tight in the face of "git add --intent-to-add": $ git add --intent-to-add file $ : oops, I don't actually want to stage that yet $ git rm --cached file error: 'empty' has staged content different from both the file and the HEAD (use -f to force removal) $ git rm -f --cached file Unfortunately, there is currently no way to distinguish between an empty file that has been added and an "intent to add" file. The ideal behavior would be to disallow the former while allowing the latter. This patch loosens the safety valve to allow the deletion only if we are deleting the cached entry and the cached content is empty. This covers the intent-to-add situation, and assumes there is little harm in not protecting users who have legitimately added an empty file. In many cases, the file will still be empty, in which case the safety valve does not trigger anyway (since the content remains untouched in the working tree). Otherwise, we do remove the fact that no content was staged, but given that the content is by definition empty, it is not terribly difficult for a user to recreate it. However, we still document the desired behavior in the form of two tests. One checks the correct removal of an intent-to-add file. The other checks that we still disallow removal of empty files, but is marked as expect_failure to indicate this compromise. If the intent-to-add feature is ever extended to differentiate between normal empty files and intent-to-add files, then the safety valve can be re-tightened. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git rm: refresh index before up-to-date checkJohannes Schindelin2008-10-08
| | | | | | | | Since "git rm" is supposed to be porcelain, we should convince it to be user friendly by refreshing the index itself. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* tests: use "git xyzzy" form (t3600 - t6999)Nanako Shiraishi2008-09-03
| | | | | | | Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2008-07-19
|\ | | | | | | | | | | | | | | | | * 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
| * builtin-rm: fix index lock file pathOlivier Marin2008-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | t/: Use "test_must_fail git" instead of "! git"Stephan Beyer2008-07-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>
* Sane use of test_expect_failureJunio C Hamano2008-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* t/t{3600,3800,5401}: do not use egrep when grep would doJunio C Hamano2008-01-05
| | | | | | | 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>
* More permissive "git-rm --cached" behavior without -f.Matthieu Moy2007-07-13
| | | | | | | | | | | | | | | | 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>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-02
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add --ignore-unmatch option to exit with zero status when no files are removed.Steven Grimm2007-04-17
| | | | | Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add --quiet option to suppress output of "rm" commands for removed files.Steven Grimm2007-04-16
| | | | | Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* t3600: update the test for updated git rmJunio C Hamano2006-12-25
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Remove unnecessary output from t3600-rm.Shawn Pearce2006-05-29
| | | | | | | | | | 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>
* t3600-rm: skip failed-remove test when we cannot make an unremovable file.Junio C Hamano2006-04-13
| | | | | | | | 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>
* workaround fat/ntfs deficiencies for t3600-rm.sh (git-rm)Alex Riesen2006-03-03
| | | | | Signed-off-by: Alex Riesen <ariesen@harmanbecker.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-rm: Fix to properly handle files with spaces, tabs, newlines, etc.Carl Worth2006-02-22
| | | | | | | 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>
* Add new git-rm command with documentationCarl Worth2006-02-22
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>