summaryrefslogtreecommitdiff
path: root/t/t1004-read-tree-m-u-wf.sh
AgeCommit message (Collapse)AuthorFilesLines
2011-05-25Teach read-tree the -n|--dry-run optionLibravatar Jens Lehmann1-11/+12
The option can be used to check if read-tree with the same set of other options like "-m" and "-u" would succeed without actually changing either the index or the working tree. The relevant tests in the t10?? range were extended to do a read-tree -n before the real read-tree to make sure neither the index nor any local files were changed with -n and the same exit code as without -n is returned. The helper functions added for that purpose reside in the new t/lib-read-tree.sh file. The only exception is #13 in t1004 ("unlinking an un-unlink-able symlink"). As this is an issue of wrong directory permissions it is not detected with -n. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18tests: A SANITY test prereq for testing if we're rootLibravatar Ævar Arnfjörð Bjarmason1-1/+1
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>
2009-03-22Use prerequisite tags to skip tests that depend on symbolic linksLibravatar Johannes Sixt1-3/+3
Many tests depend on that symbolic links work. This introduces a check that sets the prerequisite tag SYMLINKS if the file system supports symbolic links. Since so many tests have to check for this prerequisite, we do the check in test-lib.sh, so that we don't need to repeat the test in many scripts. To check for 'ln -s' failures, you can use a FAT partition on Linux: $ mkdosfs -C git-on-fat 1000000 $ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt Clone git to /mnt and $ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7 t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \ make test (These additionally skipped tests depend on POSIX permissions that FAT on Linux does not provide.) Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2008-03-18Fix read-tree not to discard errorsLibravatar Junio C Hamano1-1/+1
This fixes the issue identified with recently added tests to t1004 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-18Add tests to catch problems with un-unlinkable symlinksLibravatar Junio C Hamano1-0/+35
This currently fails not because we refuse to check out, but because we detect error but incorrectly discard it in the callchain. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-18git-merge-one-file: fix longstanding stupid thinkoLibravatar Junio C Hamano1-0/+46
When a merge result creates a new file, and when our side already has a file in the path, taking the merge result may clobber the untracked file. However, the logic to detect this situation was totally the wrong way. We should complain when the file exists, not when the file does not exist. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-16Don't update unchanged merge entriesLibravatar Linus Torvalds1-0/+41
In commit 34110cd4e394e3f92c01a4709689b384c34645d8 ("Make 'unpack_trees()' have a separate source and destination index") I introduced a really stupid bug in that it would always add merged entries with the CE_UPDATE flag set. That caused us to always re-write the file, even when it was already up-to-date in the source index. Not only is that really stupid from a performance angle, but more importantly it's actively wrong: if we have dirty state in the tree when we merge, overwriting it with the result of the merge will incorrectly overwrite that dirty state. This trivially fixes the problem - simply don't set the CE_UPDATE flag when the merge result matches the old state. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-1/+1
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-05read-tree: further loosen "working file will be lost" check.Libravatar Junio C Hamano1-8/+74
This follows up commit ed93b449 where we removed overcautious "working file will be lost" check. A new option "--exclude-per-directory=.gitignore" can be used to tell the "git-read-tree" command that the user does not mind losing contents in untracked files in the working tree, if they need to be overwritten by a merge (either a two-way "switch branches" merge, or a three-way merge). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-27merge: loosen overcautious "working file will be lost" check.Libravatar Junio C Hamano1-0/+53
The three-way merge complained unconditionally when a path that does not exist in the index is involved in a merge when it existed in the working tree. If we are merging an old version that had that path tracked, but the path is not tracked anymore, and if we are merging that old version in, the result will be that the path is not tracked. In that case we should not complain. Signed-off-by: Junio C Hamano <junkio@cox.net>