summaryrefslogtreecommitdiff
path: root/t/t0030-stripspace.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-10-27strbuf_add_commented_lines(): avoid SP-HT sequence in commented linesLibravatar Junio C Hamano1-0/+6
The strbuf_add_commented_lines() function passes a pair of prefixes, one to be used for a non-empty line, and the other for an empty line, to underlying add_lines(). The former is set to a comment char followed by a SP, while the latter is set to just the comment char. This is designed to give a SP after the comment character, e.g. "# <user text>\n", on a line with some text, and to avoid emitting an unsightly "# \n" for an empty line. Teach this machinery to also use the latter space-less prefix when the payload line begins with a tab, to show e.g. "#\t<user text>\n"; otherwise we will end up showing "# \t<user text>\n" which is similarly unsightly. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-29t0030-stripspace.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-10/+10
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 sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-16Allow custom "comment char"Libravatar Junio C Hamano1-0/+35
Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24tests: do not use implicit "git diff --no-index"Libravatar Junio C Hamano1-78/+78
As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-13grep portability fix: don't use "-e" or "-q"Libravatar Jeff King1-17/+17
System V versions of grep (such as Solaris /usr/bin/grep) don't understand either of these options. git's usage of "grep -e pattern" fell into one of two categories: 1. equivalent to "grep pattern". -e is only useful here if the pattern begins with a "-", but all of the patterns are hardcoded and do not begin with a dash. 2. stripping comments and blank lines with grep -v -e "^$" -e "^#" We can fortunately do this in the affirmative as grep '^[^#]' Uses of "-q" can be replaced with redirection to /dev/null. In many tests, however, "grep -q" is used as "if this string is in the expected output, we are OK". In this case, it is fine to just remove the "-q" entirely; it simply makes the "verbose" mode of the test slightly more verbose. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01Sane use of test_expect_failureLibravatar Junio C Hamano1-20/+20
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>
2007-07-26Teach "git stripspace" the --strip-comments optionLibravatar Johannes Schindelin1-0/+5
With --strip-comments (or short -s), git stripspace now removes lines beginning with a '#', too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-11t0030: Add tests with consecutive text lines and others with spaces added.Libravatar Carlos Rica1-0/+51
Previous tests only had paragraphs of one line. This commit adds some tests to check when many consecutive text lines are given. Also, it adds tests for checking that many lines between paragraphs are correctly reduced to one when there are tabs and spaces in those lines. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-11t0030: Remove repeated instructions and add missing &&Libravatar Carlos Rica1-24/+13
Moved some tests to another test_expect_success block. Many tests now reuse the same "expect" file. Also replacing many printf "" >expect with one >expect instruction. Added missing && which concatenated tests in some test_expect_success blocks. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-94/+94
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-26Add test script for git-stripspace.Libravatar Carlos Rica1-0/+355
These tests check some features that git-stripspace already has and those that it should manage well: Removing trailing spaces from lines, removing blank lines at the beginning and end, unifying multiple lines between paragraphs, doing the correct when there is no newline at the last line, etc. It seems that the implementation needs to save the whole line in memory to be able to manage correctly long lines with text and spaces conveniently distribuited on them. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>