summaryrefslogtreecommitdiff
path: root/t/t0020-crlf.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-02-10tests: remove last uses of C_LOCALE_OUTPUTLibravatar Ævar Arnfjörð Bjarmason1-4/+2
Remove the last uses of the C_LOCALE_OUTPUT prerequisite as well as the prerequisite itself. This is a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20), as well as the preceding commit where we removed the simpler uses of C_LOCALE_OUTPUT. Here I'm slightly refactoring a test added in 21e5ad50fc5 (safecrlf: Add mechanism to warn about irreversible crlf conversions, 2008-02-06), as well as getting rid of another "test_have_prereq C_LOCALE_OUTPUT" use. I'm not leaving the prerequisite itself in place for in-flight changes as there currently are none that introduce new tests that rely on it, and because C_LOCALE_OUTPUT is currently a noop on the master branch we likely won't have any new submissions that use it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t[01]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-5/+5
Carefully excluding t1309, which sees independent development elsewhere at the time of writing, we transition above-mentioned tests to the default branch name `main`. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -e 's/naster/nain/g' -- t[01]*.sh && git checkout HEAD -- t1309\*) Note that t5533 contains a variation of the name `master` (`naster`) that we rename here, too. This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-20t0020: don't use `test_must_fail has_cr`Libravatar Denton Liu1-9/+9
The test_must_fail function should only be used for git commands since we should assume that external commands work sanely. Since has_cr() just wraps a tr and grep pipeline, replace `test_must_fail has_cr` with `! has_cr`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/t0020-conversion-fix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t0020-conversion-fix: t0020-crlf: check the right file
2018-08-22t0020-crlf: check the right fileLibravatar SZEDER Gábor1-1/+1
In the test 'checkout with autocrlf=input' in 't0020-crlf.sh', one of the 'has_cr' checks looks at the non-existing file 'two' instead of 'dir/two'. The test still succeeds, without actually checking what it was supposed to, because this check is expected to fail anyway. As a minimal fix, fix the name of the file to be checked. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11config.c: fix regression for core.safecrlf falseLibravatar Anthony Sottile1-0/+10
A regression introduced in 8462ff43 ("convert_to_git(): safe_crlf/checksafe becomes int conv_flags", 2018-01-13) back in Git 2.17 cycle caused autocrlf rewrites to produce a warning message despite setting safecrlf=false. Signed-off-by: Anthony Sottile <asottile@umich.edu> Acked-By: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-17i18n: convert mark error messages for translationLibravatar Vasco Almeida1-1/+5
Mark error messages about CRLF for translation. Update test to reflect changes. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t0020: use test_* helpers instead of hand-rolled messagesLibravatar Jeff King1-33/+5
These tests are not wrong, but it is much shorter and more idiomatic to say "verbose" or "test_must_fail" rather than printing our own messages on failure. Likewise, there is no need to say "happy" at the end of a test; the test suite takes care of that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t0020: fix ignored exit code inside loopsLibravatar Jeff King1-35/+19
A loop like: for f in one two; do something $f || break done will correctly break out of the loop when we see a failure of one item, but the resulting exit code will always be zero. We can fix that by putting the loop into a function or subshell, but in this case it is simpler still to just unroll the loop. We do add a helper function, which hopefully makes the end result even more readable (in addition to being shorter). Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t0020: use modern test_* helpersLibravatar Jeff King1-116/+28
This test contains a lot of hand-rolled messages to show when the test fails. We can omit most of these by using "verbose" and "test_must_fail". A few of them are for update-index, but we can assume it produces reasonable error messages when it fails. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-29t0020-crlf.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-21/+21
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-06-25diff: demote core.safecrlf=true to core.safecrlf=warnLibravatar Junio C Hamano1-0/+8
Otherwise the user will not be able to start to guess where in the contents in the working tree the offending unsafe CR lies. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&, batch 2Libravatar Jonathan Nieder1-1/+1
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>
2010-05-11autocrlf: Make it work also for un-normalized repositoriesLibravatar Finn Arne Gangstad1-0/+52
Previously, autocrlf would only work well for normalized repositories. Any text files that contained CRLF in the repository would cause problems, and would be modified when handled with core.autocrlf set. Change autocrlf to not do any conversions to files that in the repository already contain a CR. git with autocrlf set will never create such a file, or change a LF only file to contain CRs, so the (new) assumption is that if a file contains a CR, it is intentional, and autocrlf should not change that. The following sequence should now always be a NOP even with autocrlf set (assuming a clean working directory): git checkout <something> touch * git add -A . (will add nothing) git commit (nothing to commit) Previously this would break for any text file containing a CR. Some of you may have been folowing Eyvind's excellent thread about trying to make end-of-line translation in git a bit smoother. I decided to attack the problem from a different angle: Is it possible to make autocrlf behave non-destructively for all the previous problem cases? Stealing the problem from Eyvind's initial mail (paraphrased and summarized a bit): 1. Setting autocrlf globally is a pain since autocrlf does not work well with CRLF in the repo 2. Setting it in individual repos is hard since you do it "too late" (the clone will get it wrong) 3. If someone checks in a file with CRLF later, you get into problems again 4. If a repository once has contained CRLF, you can't tell autocrlf at which commit everything is sane again 5. autocrlf does needless work if you know that all your users want the same EOL style. I belive that this patch makes autocrlf a safe (and good) default setting for Windows, and this solves problems 1-4 (it solves 2 by being set by default, which is early enough for clone). I implemented it by looking for CR charactes in the index, and aborting any conversion attempt if this is found. Signed-off-by: Finn Arne Gangstad <finag@pvv.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-25tests: consolidate CR removal/addition functionsLibravatar Stephen Boyd1-34/+21
append_cr(), remove_cr(), q_to_nul() and q_to_cr() are defined in multiple tests. Consolidate them into test-lib.sh so we can stop redefining them. The use of remove_cr() in t0020 to test for a CR is replaced with a new function has_cr() to accurately reflect what is intended (the output of remove_cr() was being thrown away). Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-20Add a test for checking whether gitattributes is honored by checkout.Libravatar Kristian Amlie1-0/+31
The original bug will not honor new entries in gitattributes if they are changed in the same checkout as the files they affect. It will also keep using .gitattributes, even if it is deleted in the same commit as the files it affects. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-4/+4
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>
2008-03-13more tr portability test script fixesLibravatar Jeff King1-1/+1
Dealing with NULs is not always safe with tr. On Solaris, incoming NULs are silently deleted by both the System V and UCB versions of tr. When converting to NULs, the System V version works fine, but the UCB version silently ignores the request to convert the character. This patch changes all instances of tr using NULs to use "perl -pe 'y///'" instead. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-06safecrlf: Add mechanism to warn about irreversible crlf conversionsLibravatar Steffen Prohaska1-0/+58
CRLF conversion bears a slight chance of corrupting data. autocrlf=true will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data. If you recognize such corruption early you can easily fix it by setting the conversion type explicitly in .gitattributes. Right after committing you still have the original file in your work tree and this file is not yet corrupted. You can explicitly tell git that this file is binary and git will handle the file appropriately. Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both cases CRLFs are removed in an irreversible way. For text files this is the right thing to do because CRLFs are line endings, while for binary files converting CRLFs corrupts data. This patch adds a mechanism that can either warn the user about an irreversible conversion or can even refuse to convert. The mechanism is controlled by the variable core.safecrlf, with the following values: - false: disable safecrlf mechanism - warn: warn about irreversible conversions - true: refuse irreversible conversions The default is to warn. Users are only affected by this default if core.autocrlf is set. But the current default of git is to leave core.autocrlf unset, so users will not see warnings unless they deliberately chose to activate the autocrlf mechanism. The safecrlf mechanism's details depend on the git command. The general principles when safecrlf is active (not false) are: - we warn/error out if files in the work tree can modified in an irreversible way without giving the user a chance to backup the original file. - for read-only operations that do not modify files in the work tree we do not not print annoying warnings. There are exceptions. Even though... - "git add" itself does not touch the files in the work tree, the next checkout would, so the safety triggers; - "git apply" to update a text file with a patch does touch the files in the work tree, but the operation is about text files and CRLF conversion is about fixing the line ending inconsistencies, so the safety does not trigger; - "git diff" itself does not touch the files in the work tree, it is often run to inspect the changes you intend to next "git add". To catch potential problems early, safety triggers. The concept of a safety check was originally proposed in a similar way by Linus Torvalds. Thanks to Dimitry Potapov for insisting on getting the naked LF/autocrlf=true case right. Signed-off-by: Steffen Prohaska <prohaska@zib.de>
2008-01-17Officially deprecate repo-config.Libravatar Junio C Hamano1-12/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-17the use of 'tr' in the test suite isn't really portableLibravatar H.Merijn Brand1-1/+1
Some versions of 'tr' only accept octal codes if entered with three digits, and therefor misinterpret the '\0' in the test suite. Some versions of 'tr' reject the (needless) use of character classes. Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-18attr: fix segfault in gitattributes parsing codeLibravatar Steffen Prohaska1-0/+7
git may segfault if gitattributes contains an invalid entry. A test is added to t0020 that triggers the segfault. The parsing code is fixed to avoid the crash. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-08-14attr.c: read .gitattributes from index as well.Libravatar Junio C Hamano1-0/+81
This makes .gitattributes files to be read from the index when they are not checked out to the work tree. This is in line with the way we always allowed low-level tools to operate in sparsely checked out work tree in a reasonable way. It swaps the order of new file creation and converting the blob to work tree representation; otherwise when we are in the middle of checking out .gitattributes we would notice an empty but unwritten .gitattributes file in the work tree and will ignore the copy in the index. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-19Update 'crlf' attribute semantics.Libravatar Junio C Hamano1-11/+63
This updates the semantics of 'crlf' so that .gitattributes file can say "this is text, even though it may look funny". Setting the `crlf` attribute on a path is meant to mark the path as a "text" file. 'core.autocrlf' conversion takes place without guessing the content type by inspection. Unsetting the `crlf` attribute on a path is meant to mark the path as a "binary" file. The path never goes through line endings conversion upon checkin/checkout. Unspecified `crlf` attribute tells git to apply the `core.autocrlf` conversion when the file content looks like text. Setting the `crlf` attribut to string value "input" is similar to setting the attribute to `true`, but also forces git to act as if `core.autocrlf` is set to `input` for the path. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-15Change attribute negation marker from '!' to '-'.Libravatar Junio C Hamano1-1/+1
At the same time, we do not want to allow arbitrary strings for attribute names, as we are likely to want to extend the syntax later. Allow only alnum, dash, underscore and dot for now. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-14Define 'crlf' attribute.Libravatar Junio C Hamano1-0/+24
This defines the semantics of 'crlf' attribute as an example. When a path has this attribute unset (i.e. '!crlf'), autocrlf line-end conversion is not applied. Eventually we would want to let users to build a pipeline of processing to munge blob data to filesystem format (and in the other direction) based on combination of attributes, and at that point the mechanism in convert_to_{git,working_tree}() that looks at 'crlf' attribute needs to be enhanced. Perhaps the existing 'crlf' would become the first step in the input chain, and the last step in the output chain. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17Teach core.autocrlf to 'git apply'Libravatar Junio C Hamano1-4/+15
This teaches git-apply that the data read from and written to the filesystem might need to get converted to adjust for local line-ending convention. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14t0020: add test for auto-crlfLibravatar Junio C Hamano1-0/+206
This tests lowlevel of update/checkout codepaths and some patch application. Currently, variants of "git apply" that look at the working tree files does not work, so it does not test the patch application without parameter and with --index parameter when autocrlf is set to produce CRLF files. We should add test for diff generation too. Signed-off-by: Junio C Hamano <junkio@cox.net>