aboutsummaryrefslogtreecommitdiff
path: root/t/t4124-apply-ws-rule.sh
Commit message (Collapse)AuthorAge
* t: use test_must_fail instead of hand-rolled blocksJeff King2015-03-20
| | | | | | | | | | | | | | These test scripts likely predate test_must_fail, and can be made simpler by using it (in addition to making them pass --chain-lint). The case in t6036 loses some verbosity in the failure case, but it is so tied to a specific failure mode that it is not worth keeping around (and the outcome of the test is not affected at all). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* apply: omit ws check for excluded pathsJunio C Hamano2014-08-07
| | | | | | | | | | | | | | | | | | Whitespace breakages are checked while the patch is being parsed. Disable them at the beginning of parse_chunk(), where each individual patch is parsed, immediately after we learn the name of the file the patch applies to and before we start parsing the diff contained in the patch. One may naively think that we should be able to not just skip the whitespace checks but simply fast-forward to the next patch without doing anything once use_patch() tells us that this patch is not going to be used. But in reality we cannot really skip much of the parsing in order to do such a "fast-forward", primarily because parsing "@@ -k,l +m,n @@" lines and counting the input lines is how we determine the boundaries of individual patches. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Sync with 'maint'Junio C Hamano2013-04-12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Correct common spelling mistakes in comments and tests kwset: fix spelling in comments precompose-utf8: fix spelling of "want" in error message compat/nedmalloc: fix spelling in comments compat/regex: fix spelling and grammar in comments obstack: fix spelling of similar contrib/subtree: fix spelling of accidentally git-remote-mediawiki: spelling fixes doc: various spelling fixes fast-export: fix argument name in error messages Documentation: distinguish between ref and offset deltas in pack-format i18n: make the translation of -u advice in one go
| * Correct common spelling mistakes in comments and testsStefano Lattarini2013-04-12
| | | | | | | | | | | | | | | | | | Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply --whitespace=fix: avoid running over the postimage bufferJunio C Hamano2013-03-22
|/ | | | | | | | | | | | | | | | | | | | Originally update-pre-post-images could assume that any whitespace fixing will make the result only shorter by unexpanding runs of leading SPs into HTs and removing trailing whitespaces at the end of lines. Updating the post-image we read from the patch to match the actual result can be performed in-place under this assumption. These days, however, we have tab-in-indent (aka Python) rule whose result can be longer than the original, and we do need to allocate a larger buffer than the input and replace the result. Fortunately the support for lengthening rewrite was already added when we began supporting "match while ignoring whitespace differences" mode in 86c91f91794c (git apply: option to ignore whitespace differences, 2009-08-04). We only need to correctly count the number of bytes necessary to hold the updated result and tell the function to allocate a new buffer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make the tab width used for whitespace checks configurableJohannes Sixt2010-12-01
| | | | | | | | | | | | | | A new whitespace "rule" is added that sets the tab width to use for whitespace checks and fix-ups and replaces the hard-coded constant 8. Since the setting is part of the rules, it can be set per file using .gitattributes. The new configuration is backwards compatible because older git versions simply ignore unknown whitespace rules. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/maint-apply-tab-in-indent-fix' into HEADJunio C Hamano2010-12-01
|\ | | | | | | | | * js/maint-apply-tab-in-indent-fix: apply --whitespace=fix: fix tab-in-indent
| * apply --whitespace=fix: fix tab-in-indentJohannes Sixt2010-12-01
| | | | | | | | | | | | | | | | | | | | | | | | | | When the whitespace rule tab-in-indent is enabled, apply --whitespace=fix replaces tabs by the appropriate amount of blanks. The code used "dst->len % 8" as the criterion to stop adding blanks. But it forgot that dst holds more than just the current line. Consequently, the modulus was computed correctly only for the first added line, but not for the second and subsequent lines. Fix it. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t4124 (apply --whitespace): use test_might_failJonathan Nieder2010-11-09
| | | | | | | | | | | | | | | | | | | | Use test_might_fail instead of ignoring the exit status from git config --unset, and let the exit status propagate past rm -f (which does not fail on ENOENT). Otherwise bugs that lead git config to crash would not be detected when this test runs. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | tests: add missing &&, batch 2Jonathan Nieder2010-11-09
| | | | | | | | | | | | | | | | | | | | | | Same rules as before: this patch only adds " &&" to the end of some lines in the test suite. Intended to be applied on top of or squashed with the last batch if they look okay. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'gv/portable'Junio C Hamano2010-06-21
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * gv/portable: test-lib: use DIFF definition from GIT-BUILD-OPTIONS build: propagate $DIFF to scripts Makefile: Tru64 portability fix Makefile: HP-UX 10.20 portability fixes Makefile: HPUX11 portability fixes Makefile: SunOS 5.6 portability fix inline declaration does not work on AIX Allow disabling "inline" Some platforms lack socklen_t type Make NO_{INET_NTOP,INET_PTON} configured independently Makefile: some platforms do not have hstrerror anywhere git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition test_cmp: do not use "diff -u" on platforms that lack one fixup: do not unconditionally disable "diff -u" tests: use "test_cmp", not "diff", when verifying the result Do not use "diff" found on PATH while building and installing enums: omit trailing comma for portability Makefile: -lpthread may still be necessary when libc has only pthread stubs Rewrite dynamic structure initializations to runtime assignment Makefile: pass CPPFLAGS through to fllow customization Conflicts: Makefile wt-status.h
| * | tests: use "test_cmp", not "diff", when verifying the resultGary V. Vaughan2010-05-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In tests, call test_cmp rather than raw diff where possible (i.e. if the output does not go to a pipe), to allow the use of, say, 'cmp' when the default 'diff -u' is not compatible with a vendor diff. When that is not possible, use $DIFF, as set in GIT-BUILD-OPTIONS. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'bg/apply-blank-trailing-context'Junio C Hamano2010-05-08
|\ \ \ | |_|/ |/| | | | | | | | * bg/apply-blank-trailing-context: apply: Allow blank *trailing* context lines to match beyond EOF
| * | apply: Allow blank *trailing* context lines to match beyond EOFBjörn Gustavsson2010-04-07
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 51667147be, "git apply --whitespace=fix" was extended to allow a blank context line to match beyond the end of the file, but only if the context line was in the leading part of the hunk (i.e. the hunk inserted additional contents at the end of the file). Drop the restriction that the context line must be in the leading part of the hunk, thus allowing a file to be changed from: a (blank line) to: b a (blank line) Note that the blank line will be kept, because "--whitespace=fix" only removes trailing blank lines that a hunk would add, never trailing blank lines in the context. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | whitespace: tests for git-apply --whitespace=fix with tab-in-indentChris Webb2010-04-04
|/ | | | | Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t4124: Add additional tests of --whitespace=fixBjörn Gustavsson2010-03-06
| | | | | Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/maint-1.6.0-blank-at-eof' (early part) into ↵Junio C Hamano2009-09-15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | jc/maint-blank-at-eof * 'jc/maint-1.6.0-blank-at-eof' (early part): diff --whitespace: fix blank lines at end core.whitespace: split trailing-space into blank-at-{eol,eof} diff --color: color blank-at-eof diff --whitespace=warn/error: fix blank-at-eof check diff --whitespace=warn/error: obey blank-at-eof diff.c: the builtin_diff() deals with only two-file comparison apply --whitespace: warn blank but not necessarily empty lines at EOF apply --whitespace=warn/error: diagnose blank at EOF apply.c: split check_whitespace() into two apply --whitespace=fix: detect new blank lines at eof correctly apply --whitespace=fix: fix handling of blank lines at the eof
| * apply --whitespace: warn blank but not necessarily empty lines at EOFJunio C Hamano2009-09-04
| | | | | | | | | | | | | | | | The whitespace error of adding blank lines at the end of file should trigger if you added a non-empty line at the end, if the contents of the line is full of whitespaces. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * apply --whitespace=warn/error: diagnose blank at EOFJunio C Hamano2009-09-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git apply" strips new blank lines at EOF under --whitespace=fix option, but neigher --whitespace=warn nor --whitespace=error paid any attention to these errors. Introduce a new whitespace error class, blank-at-eof, to make the whitespace error handling more consistent. The patch adds a new "linenr" field to the struct fragment in order to record which line the hunk started in the input file, but this is needed solely for reporting purposes. The detection of this class of whitespace errors cannot be done while parsing a patch like we do for all the other classes of whitespace errors. It instead has to wait until we find where to apply the hunk, but at that point, we do not have an access to the original line number in the input file anymore, hence the new field. Depending on your point of view, this may be a bugfix that makes warn and error in line with fix. Or you could call it a new feature. The line between them is somewhat fuzzy in this case. Strictly speaking, triggering more errors than before is a change in behaviour that is not backward compatible, even though the reason for the change is because the code was not checking for an error that it should have. People who do not want added blank lines at EOF to trigger an error can disable the new error class. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * apply --whitespace=fix: detect new blank lines at eof correctlyJunio C Hamano2009-09-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The command tries to strip blank lines at the end of the file added by a patch. It is done by first detecting if a hunk in patch has additional blank lines at the end of itself, and if so checking if such a hunk applies at the end of file. This patch addresses a bug in the logic to implement the former (the previous one addressed a bug in the latter). If the original ends with blank lines, often the patch hunk ends like this: @@ -l,5 +m,7 @@$ _context$ _context$ -deleted$ +$ +$ +$ _$ _$ where _ stands for SP and $ shows a end-of-line. This example patch adds three trailing blank lines, but the code fails to notice it, because it only pays attention to added blank lines at the very end of the hunk. In this example, the three added blank lines do not appear textually at the end in the patch, even though you can see that they are indeed added at the end, if you rearrange the diff like this: @@ -l,5 +m,7 @@$ _context$ _context$ -deleted$ _$ _$ +$ +$ +$ The fix is not to reset the number of (candidate) added blank lines at the end when the loop sees a context line that is empty. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * apply --whitespace=fix: fix handling of blank lines at the eofJunio C Hamano2009-09-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | b94f2ed (builtin-apply.c: make it more line oriented, 2008-01-26) broke the logic used to detect if a hunk adds blank lines at the end of the file. With the new code after that commit: - img holds the contents of the file that the hunk is being applied to; - preimage has the lines the hunk expects to be in img; and - postimage has the lines the hunk wants to update the part in img that corresponds to preimage with. and we need to compare if the last line of preimage (not postimage) matches the last line of img to see if the hunk applies at the end of the file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Fix severe breakage in "git-apply --whitespace=fix"Junio C Hamano2009-07-25
| | | | | | | | | | | | | | 735c674 (Trailing whitespace and no newline fix, 2009-07-22) completely broke --whitespace=fix, causing it to lose all the empty lines in a patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Trailing whitespace and no newline fixSZEDER Gábor2009-07-22
|/ | | | | | | | | | | | | If a patch adds a new line to the end of a file and this line ends with one trailing whitespace character and has no newline, then '--whitespace=fix' currently does not remove that trailing whitespace. This patch fixes this by removing the check for trailing whitespace at the end of the line at a hardcoded offset which does not take the eventual absence of newline into account. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 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>
* Use gitattributes to define per-path whitespace ruleJunio C Hamano2007-12-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | The `core.whitespace` configuration variable allows you to define what `diff` and `apply` should consider whitespace errors for all paths in the project (See gitlink:git-config[1]). This attribute gives you finer control per path. For example, if you have these in the .gitattributes: frotz whitespace nitfol -whitespace xyzzy whitespace=-trailing all types of whitespace problems known to git are noticed in path 'frotz' (i.e. diff shows them in diff.whitespace color, and apply warns about them), no whitespace problem is noticed in path 'nitfol', and the default types of whitespace problems except "trailing whitespace" are noticed for path 'xyzzy'. A project with mixed Python and C might want to have: *.c whitespace *.py whitespace=-indent-with-non-tab in its toplevel .gitattributes file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply: teach whitespace_rulesJunio C Hamano2007-11-24
We earlier introduced core.whitespace to allow users to tweak the definition of what the "whitespace errors" are, for the purpose of diff output highlighting. This teaches the same to git-apply, so that the command can both detect (when --whitespace=warn option is given) and fix (when --whitespace=fix option is given) as configured. Signed-off-by: Junio C Hamano <gitster@pobox.com>