summaryrefslogtreecommitdiff
path: root/t/t3600-rm.sh
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'sb/submodule-short-status'Junio C Hamano2017-04-191-5/+13
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The output from "git status --short" has been extended to show various kinds of dirtyness in submodules differently; instead of to "M" for modified, 'm' and '?' can be shown to signal changes only to the working tree of the submodule but not the commit that is checked out. * sb/submodule-short-status: submodule.c: correctly handle nested submodules in is_submodule_modified short status: improve reporting for submodule changes submodule.c: stricter checking for submodules in is_submodule_modified submodule.c: port is_submodule_modified to use porcelain 2 submodule.c: convert is_submodule_modified to use strbuf_getwholeline submodule.c: factor out early loop termination in is_submodule_modified submodule.c: use argv_array in is_submodule_modified
| * submodule.c: correctly handle nested submodules in is_submodule_modifiedsb/submodule-short-statusStefan Beller2017-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Suppose I have a superproject 'super', with two submodules 'super/sub' and 'super/sub1'. 'super/sub' itself contains a submodule 'super/sub/subsub'. Now suppose I run, from within 'super': echo hi >sub/subsub/stray-file echo hi >sub1/stray-file Currently we get would see the following output in git-status: git status --short m sub ? sub1 With this patch applied, the untracked file in the nested submodule is displayed as an untracked file on the 'super' level as well. git status --short ? sub ? sub1 This doesn't change the output of 'git status --porcelain=1' for nested submodules, because its output is always ' M' for either untracked files or local modifications no matter the nesting level of the submodule. 'git status --porcelain=2' is affected by this change in a nested submodule, though. Without this patch it would report the direct submodule as modified and having no untracked files. With this patch it would report untracked files. Chalk this up as a bug fix. This bug fix also affects the default output (non-short, non-porcelain) of git-status, which is not tested here. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * short status: improve reporting for submodule changesStefan Beller2017-03-291-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If I add an untracked file to a submodule or modify a tracked file, currently "git status --short" treats the change in the same way as changes to the current HEAD of the submodule: $ git clone --quiet --recurse-submodules https://gerrit.googlesource.com/gerrit $ echo hello >gerrit/plugins/replication/stray-file $ sed -i -e 's/.*//' gerrit/plugins/replication/.mailmap $ git -C gerrit status --short M plugins/replication This is by analogy with ordinary files, where "M" represents a change that has not been added yet to the index. But this change cannot be added to the index without entering the submodule, "git add"-ing it, and running "git commit", so the analogy is counterproductive. Introduce new status letters " ?" and " m" for this. These are similar to the existing "??" and " M" but mean that the submodule (not the parent project) has new untracked files and modified files, respectively. The user can use "git add" and "git commit" from within the submodule to add them. Changes to the submodule's HEAD commit can be recorded in the index with a plain "git add -u" and are shown with " M", like today. To avoid excessive clutter, show at most one of " ?", " m", and " M" for the submodule. They represent increasing levels of change --- the last one that applies is shown (e.g., " m" if there are both modified files and untracked files in the submodule, or " M" if the submodule's HEAD has been modified and it has untracked files). While making these changes, we need to make sure to not break porcelain level 1, which shares code with "status --short". We only change "git status --short". Non-short "git status" and "git status --porcelain=2" already handle these cases by showing more detail: $ git -C gerrit status --porcelain=2 1 .M S.MU 160000 160000 160000 305c864db28eb0c77c8499bc04c87de3f849cf3c 305c864db28eb0c77c8499bc04c87de3f849cf3c plugins/replication $ git -C gerrit status [...] modified: plugins/replication (modified content, untracked content) Scripts caring about these distinctions should use --porcelain=2. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t3600: rename test to describe its functionalitysb/t3600-rephraseStefan Beller2017-03-221-1/+1
|/ | | | | | | | | | This was an oversight in 55856a35b2 (rm: absorb a submodules git dir before deletion, 2016-12-27), as the body of the test changed without adapting the test subject. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'sb/submodule-rm-absorb'Junio C Hamano2017-01-181-24/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | "git rm" used to refuse to remove a submodule when it has its own git repository embedded in its working tree. It learned to move the repository away to $GIT_DIR/modules/ of the superproject instead, and allow the submodule to be deleted (as long as there will be no loss of local modifications, that is). * sb/submodule-rm-absorb: rm: absorb a submodules git dir before deletion submodule: rename and add flags to ok_to_remove_submodule submodule: modernize ok_to_remove_submodule to use argv_array submodule.h: add extern keyword to functions
| * rm: absorb a submodules git dir before deletionStefan Beller2016-12-271-26/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When deleting a submodule, we need to keep the actual git directory around, such that we do not lose local changes in there and at a later checkout of the submodule we don't need to clone it again. Now that the functionality is available to absorb the git directory of a submodule, rewrite the checking in git-rm to not complain, but rather relocate the git directories inside the superproject. An alternative solution was discussed to have a function `depopulate_submodule`. That would couple the check for its git directory and possible relocation before the the removal, such that it is less likely to miss the check in the future. But the indirection with such a function added seemed also complex. The reason for that was that this possible move of the git directory was also implemented in `ok_to_remove_submodule`, such that this function could truthfully answer whether it is ok to remove the submodule. The solution proposed here defers all these checks to the caller. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'sb/t3600-cleanup'Junio C Hamano2016-12-191-73/+51
|\ \ | |/ |/| | | | | | | | | | | Code cleanup. * sb/t3600-cleanup: t3600: slightly modernize style t3600: remove useless redirect
| * t3600: slightly modernize stylesb/t3600-cleanupStefan Beller2016-12-121-73/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the space between redirection and file name. Also remove unnecessary invocations of subshells, such as (cd submod && echo X >untracked ) && as there is no point of having the shell for functional purposes. In case of a single Git command use the `-C` option to let Git cd into the directory. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * t3600: remove useless redirectStefan Beller2016-12-051-1/+1
| | | | | | | | | | | | | | | | In the next line the `actual` is overwritten again, so no need to redirect the output of checkout into that file. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | pathspec: warn on empty strings as pathspecEmily Xie2016-06-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An empty string as a pathspec element matches all paths. A buggy script, however, could accidentally assign an empty string to a variable that then gets passed to a Git command invocation, e.g.: path=... compute a path to be removed in $path ... git rm -r "$paht" which would unintentionally remove all paths in the current directory. The fix for this issue requires a two-step approach. As there may be existing scripts that knowingly use empty strings in this manner, the first step simply gives a warning that (1) tells that an empty string will become an invalid pathspec element and (2) asks the user to use "." if they mean to match all. For step two, a follow-up patch several release cycles later will remove the warning and throw an error instead. This patch is the first step. Signed-off-by: Emily Xie <emilyxxie@gmail.com> Reported-by: David Turner <novalis@novalis.org> Mentored-by: Michail Denchev <mdenchev@gmail.com> Thanks-to: Sarah Sharp <sarah@thesharps.us> and James Sharp <jamey@minilop.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/mingw-tests'Junio C Hamano2016-02-171-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test scripts have been updated to remove assumptions that are not portable between Git for POSIX and Git for Windows, or to skip ones with expectations that are not satisfiable on Git for Windows. * js/mingw-tests: (21 commits) gitignore: ignore generated test-fake-ssh executable mingw: do not bother to test funny file names mingw: skip a test in t9130 that cannot pass on Windows mingw: handle the missing POSIXPERM prereq in t9124 mingw: avoid illegal filename in t9118 mingw: mark t9100's test cases with appropriate prereqs t0008: avoid absolute path mingw: work around pwd issues in the tests mingw: fix t9700's assumption about directory separators mingw: skip test in t1508 that fails due to path conversion tests: turn off git-daemon tests if FIFOs are not available mingw: disable mkfifo-based tests mingw: accomodate t0060-path-utils for MSYS2 mingw: fix t5601-clone.sh mingw: let lstat() fail with errno == ENOTDIR when appropriate mingw: try to delete target directory before renaming mingw: prepare the TMPDIR environment variable for shell scripts mingw: factor out Windows specific environment setup Git.pm: stop assuming that absolute paths start with a slash mingw: do not trust MSYS2's MinGW gettext.sh ...
| * | mingw: do not bother to test funny file namesJohannes Schindelin2016-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MSYS2 actually allows to create files or directories whose names contain tabs, newlines or colors, even if plain Win32 API cannot access them. As we are using an MSYS2 bash to run the tests, such files or directories are created successfully, but Git itself has no chance to work with them because it is a regular Windows program, hence limited by the Win32 API. With this change, on Windows otherwise failing tests in t3300-funny-names.sh, t3600-rm.sh, t3703-add-magic-pathspec.sh, t3902-quoted.sh, t4016-diff-quote.sh, t4135-apply-weird-filenames.sh, t9200-git-cvsexportcommit.sh, and t9903-bash-prompt.sh are skipped. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | t/t3600-rm.sh: use the $( ... ) construct for command substitutionElia Pinto2015-12-281-2/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t3600: fix &&-chain breakage for setup commandsJeff King2015-03-201-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As with the earlier patch to fix "trivial" &&-chain breakage, these missing "&&" operators are not a serious problem (e.g., we do not expect "echo" to fail). Ironically, however, inserting them shows that some of the commands _do_ fail. Specifically, some of the tests start by making sure we are at a commit with the string "content" in the file "foo". However, running "git commit" may fail because the previous test left us in that state already, and there is nothing to commit. We could remove these commands entirely, but they serve to document the test's assumptions, as well as make it robust when an earlier test has failed. We could use test_might_fail to handle all cases, but that would miss an unrelated failure to make the commit. Instead, we can just pass the --allow-empty flag to git-commit, which means that it will not complain if our setup is a noop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t: fix trivial &&-chain breakageJeff King2015-03-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t: fix severe &&-chain breakageJeff King2015-03-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | These are tests which are missing a link in their &&-chain, in a location which causes a significant portion of the test to be missed (e.g., the test effectively does nothing, or consists of a long string of actions and output comparisons, and we throw away the exit code of at least one part of the string). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | tests: don't rely on strerror text when testing rmdir failurecb/aixCharles Bailey2014-03-311-2/+1
|/ | | | | | | | | | | AIX doesn't make a distiction between EEXIST and ENOTEMPTY; relying on the strerror string for the rmdir failure is fragile. Just test that the start of the string matches the Git controlled "failed to rmdir..." error. The exact text of the OS generated error string isn't important to the test. Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rm: better document side effects when removing a submodulejl/submodule-mv-checkout-caveatJens Lehmann2014-01-071-0/+16
| | | | | | | | | | | | | | The "Submodules" section of the "git rm" documentation mentions what will happen when a submodule with a gitfile gets removed with newer git. But it doesn't talk about what happens when the user changes between commits before and after the removal, which does not remove the submodule from the work tree like using the rm command did the first time. Explain what happens and what the user has to do manually to fix that in the new BUGS section. Also document this behavior in a new test. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'sg/t3600-nul-sha1-fix'Junio C Hamano2013-10-301-7/+4
|\ | | | | | | | | * sg/t3600-nul-sha1-fix: t3600: fix broken "choking git rm" test
| * t3600: fix broken "choking git rm" testsg/t3600-nul-sha1-fixSZEDER Gábor2013-10-161-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test 'choking "git rm" should not let it die with cruft' is supposed to check 'git rm's behavior when interrupted by provoking a SIGPIPE while 'git rm' is busily deleting files from a specially crafted index. This test is silently broken for the following reasons: - The test crafts a special index by feeding a large number of index entries with null shas to 'git update-index --index-info'. It was OK back then when this test was introduced in commit 0693f9ddad (Make sure lockfiles are unlocked when dying on SIGPIPE, 2008-12-18), but since commit 4337b5856f (do not write null sha1s to on-disk index, 2012-07-28) null shas are not allowed in the on-disk index causing 'git update-index' to error out. - The barfing 'git update-index --index-info' should fail the test, but it remains unnoticed because of the severely broken && chain: the test's result depends solely on whether there is a stale lock file left behind, but after 'git update-index' errors out 'git rm' won't be executed at all. To fix this test feed only non-null shas to 'git update-index' and restore the && chain (partly by adding a missing && and by using the test_when_finished helper instead of manual cleanup). Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rm: delete .gitmodules entry of submodules removed from the work treeJens Lehmann2013-08-061-6/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rm: introduce advice.rmHints to shorten messagesMathieu Lienard--Mayor2013-06-121-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce advice.rmHints to choose whether to display advice or not when git rm fails. Defaults to true, in order to preserve current behavior. As an example, the message: error: 'foo.txt' has changes staged in the index (use --cached to keep the file, or -f to force removal) would look like, with advice.rmHints=false: error: 'foo.txt' has changes staged in the index Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr> Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rm: better error message on failure for multiple filesMathieu Lienard--Mayor2013-06-121-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When 'git rm' fails, it now displays a single message with the list of files involved, instead of displaying a list of messages with one file each. As an example, the old message: error: 'foo.txt' has changes staged in the index (use --cached to keep the file, or -f to force removal) error: 'bar.txt' has changes staged in the index (use --cached to keep the file, or -f to force removal) would now be displayed as: error: the following files have changes staged in the index: foo.txt bar.txt (use --cached to keep the file, or -f to force removal) Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr> Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t3600: document failure of rm across symbolic linksJeff King2013-04-041-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a symlink "d" that points to a directory, we should not be able to remove "d/f". In the normal case, where "d/f" does not exist in the index, we already disallow this, as we only remove things that git knows about in the index. So for something like: ln -s /outside/repo foo git add foo git rm foo/bar we will properly produce an error (as there is no index entry for foo/bar). However, if there is an index entry for the path (e.g., because the movement is due to working tree changes that have not yet been reflected in the index), we will happily delete it, even though the path we delete from the filesystem is not the same as the path in the index. This patch documents that failure with a test. While this is a bug, it should not be possible to cause serious data loss with it. For any path that does not have an index entry, we will complain and bail. For a path which does have an index entry, we will do the usual up-to-date content check. So even if the deleted path in the filesystem is not the same as the one we are removing from the index, we do know that they at least have the same content, and that the content is included in HEAD. That means the worst case is not the accidental loss of content, but rather confusion by the user when a copy of a file another part of the tree is removed. Which makes this bug a minor and hard-to-trigger annoyance rather than a data-loss bug (and hence the fix can be saved for a rainy day when somebody feels like working on it). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t3600: test behavior of reverse-d/f conflictJeff King2013-04-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit taught "rm" that it is safe to consider "d/f" removed when "d" has become a non-directory. This patch adds a test for the opposite: a file "d" that becomes a directory. In this case, "git rm" does need to complain, because we should not be removing arbitrary content under "d". Git already behaves correctly, but let's make sure that remains the case by protecting the behavior with a test. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rm: do not complain about d/f conflicts during deletionJeff King2013-04-041-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we used to have an index entry "d/f", but "d" has been replaced by a non-directory entry, the user may still want to run "git rm" to delete the stale index entry. They could use "git rm --cached" to just touch the index, but "git rm" should also work: we explicitly try to handle the case that the file has already been removed from the working tree. However, because unlinking "d/f" in this case will not yield ENOENT, but rather ENOTDIR, we do not notice that the file is already gone. Instead, we report it as an error. The simple solution is to treat ENOTDIR in this case exactly like ENOENT; all we want to know is whether the file is already gone, and if a leading path is no longer a directory, then by definition the sub-path is gone. Reported-by: jpinheiro <7jpinheiro@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t3600: Avoid "cp -a", which is a GNUismJunio C Hamano2012-12-191-3/+3
| | | | | | | | | | | | | | | | With d4a7ffa (tests: "cp -a" is a GNUism, 2012-10-08), we got rid of most of them, but the ones in a topic that was still in flight were missed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Teach rm to remove submodules when given with a trailing '/'Jens Lehmann2012-11-231-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Doing a "git rm submod/" on a submodule results in an error: fatal: pathspec 'submod/' did not match any files This is really inconvenient as e.g. using TAB completion in a shell on a submodule automatically adds the trailing '/' when it completes the path of the submodule directory. The user has then to remove the '/' herself to make a "git rm" succeed. Doing a "git rm -r somedir/" is working fine, so there is no reason why that shouldn't work for submodules too. Teach git rm to not error out when a '/' is appended to the path of a submodule. Achieve this by chopping off trailing slashes from the path names given if they represent directories. Add tests to make sure that logic only applies to directories and not to files. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | submodule: teach rm to remove submodules unless they contain a git directoryJens Lehmann2012-09-291-0/+343
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/fix-diff-files-unmerged'Junio C Hamano2011-05-061-2/+1
|\ | | | | | | | | | | | | | | * 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-231-2/+1
| | | | | | | | | | | | | | 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-141-1/+1
|/ | | | | | | | | | | | | 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-181-16/+0
| | | | | | | | | | | | | | | | | | | | | 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-251-1/+1
| | | | | | | | | | 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-181-0/+8
| | | | | | | | | | | | | | 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-221-28/+30
| | | | | | | | | | | | | | 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-191-1/+2
| | | | | | | | 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-191-1/+1
| | | | | | | | | | | 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-211-0/+17
| | | | | | | | | 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-281-2/+2
| | | | | | | | | | | | | | | | | | 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-221-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-081-8/+17
| | | | | | | | 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-031-2/+2
| | | | | | | 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-191-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
| * builtin-rm: fix index lock file pathOlivier Marin2008-07-191-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>
* | t/: Use "test_must_fail git" instead of "! git"Stephan Beyer2008-07-131-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>
* Sane use of test_expect_failureJunio C Hamano2008-02-011-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>
* t/t{3600,3800,5401}: do not use egrep when grep would doJunio C Hamano2008-01-051-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>
* More permissive "git-rm --cached" behavior without -f.Matthieu Moy2007-07-131-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>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-021-24/+24
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status