summaryrefslogtreecommitdiff
path: root/t/t4135-apply-weird-filenames.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-08-06t: factor out FUNNYNAMES as shared lazy prereqLibravatar William Chargin1-9/+1
A fair number of tests need to check that the filesystem supports file names including "funny" characters, like newline, tab, and double-quote. Jonathan Nieder suggested that this be extracted into a lazy prereq in the top-level `test-lib.sh`. This patch effects that change. The FUNNYNAMES prereq now uniformly requires support for newlines, tabs, and double-quotes in filenames. This very slightly decreases the power of some tests, which might have run previously on a system that supports (e.g.) newlines and tabs but not double-quotes, but now will not. This seems to me like an acceptable tradeoff for consistency. One test (`t/t9902-completion.sh`) defined FUNNYNAMES to further require the separators \034 through \037, the test for which was implemented using the Bash-specific $'\034' syntax. I've elected to leave this one as is, renaming it to FUNNIERNAMES. After this patch, `git grep 'test_\(set\|lazy\)_prereq.*FUNNYNAMES'` has only one result. Signed-off-by: William Chargin <wchargin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-15apply: handle Subversion diffs with /dev/null gracefullyLibravatar Tatyana Krasnukha1-1/+1
Subversion generates diffs that can contain lines like this one: --- /dev/null (nonexistent) Let's teach Git's apply machinery to handle such a line gracefully. This fixes https://github.com/git-for-windows/git/isues/1489 Signed-off-by: Tatyana Krasnukha <tatyana@synopsys.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-15apply: demonstrate a problem applying svn diffsLibravatar Johannes Schindelin1-0/+17
Subversion generates diffs that contain funny ---/+++ lines containing more than just the file names. Example: --- a/trunk/README (revision 4711) +++ /dev/null (nonexistent) Let's add a test case demonstrating that apply cannot handle the /dev/null line (although it can handle the trunk/README line just fine). Reported in https://github.com/git-for-windows/git/issues/1489 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-28mingw: do not bother to test funny file namesLibravatar Johannes Schindelin1-1/+2
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>
2010-11-10apply: handle patches with funny filename and colon in timezoneLibravatar Jonathan Nieder1-0/+16
Some patches have a timezone formatted like '-08:00' instead of '-0800' in their ---/+++ lines (e.g. http://lwn.net/Articles/131729/). Take this into account when searching for the start of the timezone (which is the end of the filename). This does not actually affect the outcome of patching unless (1) a file being patched has a non-' ' whitespace character (e.g., tab) in its filename, or (2) the patch is whitespace-damaged, so the tab between filename and timestamp has been replaced with spaces. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21apply: handle traditional patches with space in filenameLibravatar Jonathan Nieder1-2/+2
To discover filenames from the --- and +++ lines in a traditional unified diff, currently "git apply" scans forward for a whitespace character on each line and stops there. It can't use the whole line because "diff -u" likes to include timestamps, like so: --- foo 2000-07-12 16:56:50.020000414 -0500 +++ bar 2010-07-12 16:56:50.020000414 -0500 The whitespace-seeking heuristic works great, even when the tab has been converted to spaces by some email + copy-and-paste related corruption. Except for one problem: if the filename itself contains whitespace, the inferred filename will be too short. When Giuseppe ran into this problem, it was for a file creation patch (for debian/licenses/LICENSE.global BSD-style Chromium). So one can't use the list of files present in the index to deduce an appropriate filename (not to mention that way lies madness; see v0.99~402, 2005-05-31). Instead, look for a timestamp and use that if present to mark the end of the filename. If no timestamp is present, the old heuristic is used, with one exception: the space character \040 is not considered terminating whitespace any more unless it is followed by a timestamp. Reported-by: Giuseppe Iuculano <iuculano@debian.org> Acked-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21tests: exercise "git apply" with weird filenamesLibravatar Jonathan Nieder1-0/+75
Check that "git apply" can cope with strange filenames, particularly filenames with spaces. Not all platforms have a sane enough diff -u and expand to reliably create the such patches and maybe future versions of GNU diff will handle funny characters differently, so this uses pre-generated patches. The script used to generate them is in t/t4135/make-patches. Filenames with tabs are not usable on NTFS; use something like the FUNNYNAMES prerequisite from v1.3.0-rc1~67 (2006-03-03) to skip the relevant tests when appropriate. The detection is not shared in test-lib.sh to avoid wasting time while running other test scripts. Backslash is the path separator on Windows, so do not used it in file names there (v1.6.3-rc0~93^2~6, 2009-03-13). Finally, filenames starting with a quotation mark do not behave well in msys (see v1.7.0-rc0~94^2, t4030, t4031: work around bogus MSYS bash path conversion, 2010-01-01), so skip those tests on Windows, too. Helped-by: Andreas Schwab <schwab@linux-m68k.org> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>