2007-02-14 22:54:00 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='CRLF conversion'
|
|
|
|
|
2020-11-18 23:44:21 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
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>
2020-11-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2021-11-16 18:27:38 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2007-02-14 22:54:00 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
2010-01-26 00:33:57 +00:00
|
|
|
has_cr() {
|
|
|
|
tr '\015' Q <"$1" | grep Q >/dev/null
|
2007-02-14 22:54:00 +00:00
|
|
|
}
|
|
|
|
|
2015-03-25 05:28:44 +00:00
|
|
|
# add or remove CRs to disk file in-place
|
|
|
|
# usage: munge_cr <append|remove> <file>
|
|
|
|
munge_cr () {
|
|
|
|
"${1}_cr" <"$2" >tmp &&
|
|
|
|
mv tmp "$2"
|
|
|
|
}
|
|
|
|
|
2007-02-14 22:54:00 +00:00
|
|
|
test_expect_success setup '
|
|
|
|
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf false &&
|
2007-02-14 22:54:00 +00:00
|
|
|
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines Hello world how are you >one &&
|
2007-02-14 22:54:00 +00:00
|
|
|
mkdir dir &&
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines I am very very fine thank you >dir/two &&
|
|
|
|
test_write_lines Oh here is NULQin text here | q_to_nul >three &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git add . &&
|
|
|
|
|
|
|
|
git commit -m initial &&
|
|
|
|
|
2014-04-28 12:57:26 +00:00
|
|
|
one=$(git rev-parse HEAD:one) &&
|
|
|
|
dir=$(git rev-parse HEAD:dir) &&
|
|
|
|
two=$(git rev-parse HEAD:dir/two) &&
|
|
|
|
three=$(git rev-parse HEAD:three) &&
|
2007-02-14 22:54:00 +00:00
|
|
|
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines Some extra lines here >>one &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git diff >patch.file &&
|
2014-04-28 12:57:26 +00:00
|
|
|
patched=$(git hash-object --stdin <one) &&
|
2015-03-25 05:31:41 +00:00
|
|
|
git read-tree --reset -u HEAD
|
2007-02-14 22:54:00 +00:00
|
|
|
'
|
|
|
|
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
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-02-06 11:25:58 +00:00
|
|
|
test_expect_success 'safecrlf: autocrlf=input, all CRLF' '
|
|
|
|
|
|
|
|
git config core.autocrlf input &&
|
|
|
|
git config core.safecrlf true &&
|
|
|
|
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines I am all CRLF | append_cr >allcrlf &&
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git add allcrlf
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
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-02-06 11:25:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'safecrlf: autocrlf=input, mixed LF/CRLF' '
|
|
|
|
|
|
|
|
git config core.autocrlf input &&
|
|
|
|
git config core.safecrlf true &&
|
|
|
|
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines Oh here is CRLFQ in text | q_to_cr >mixed &&
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git add mixed
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
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-02-06 11:25:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'safecrlf: autocrlf=true, all LF' '
|
|
|
|
|
|
|
|
git config core.autocrlf true &&
|
|
|
|
git config core.safecrlf true &&
|
|
|
|
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines I am all LF >alllf &&
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git add alllf
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
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-02-06 11:25:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'safecrlf: autocrlf=true mixed LF/CRLF' '
|
|
|
|
|
|
|
|
git config core.autocrlf true &&
|
|
|
|
git config core.safecrlf true &&
|
|
|
|
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines Oh here is CRLFQ in text | q_to_cr >mixed &&
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git add mixed
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
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-02-06 11:25:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'safecrlf: print warning only once' '
|
|
|
|
|
|
|
|
git config core.autocrlf input &&
|
|
|
|
git config core.safecrlf warn &&
|
|
|
|
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines I am all LF >doublewarn &&
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
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-02-06 11:25:58 +00:00
|
|
|
git add doublewarn &&
|
|
|
|
git commit -m "nowarn" &&
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines Oh here is CRLFQ in text | q_to_cr >doublewarn &&
|
2016-10-17 13:15:27 +00:00
|
|
|
git add doublewarn 2>err &&
|
2021-02-11 01:53:52 +00:00
|
|
|
grep "CRLF will be replaced by LF" err >err.warnings &&
|
|
|
|
test_line_count = 1 err.warnings
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
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-02-06 11:25:58 +00:00
|
|
|
'
|
|
|
|
|
2013-06-24 21:35:04 +00:00
|
|
|
|
|
|
|
test_expect_success 'safecrlf: git diff demotes safecrlf=true to warn' '
|
|
|
|
git config core.autocrlf input &&
|
|
|
|
git config core.safecrlf true &&
|
|
|
|
git diff HEAD
|
|
|
|
'
|
|
|
|
|
|
|
|
|
2018-06-04 20:17:42 +00:00
|
|
|
test_expect_success 'safecrlf: no warning with safecrlf=false' '
|
|
|
|
git config core.autocrlf input &&
|
|
|
|
git config core.safecrlf false &&
|
|
|
|
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines I am all CRLF | append_cr >allcrlf &&
|
2018-06-04 20:17:42 +00:00
|
|
|
git add allcrlf 2>err &&
|
|
|
|
test_must_be_empty err
|
|
|
|
'
|
|
|
|
|
|
|
|
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
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-02-06 11:25:58 +00:00
|
|
|
test_expect_success 'switch off autocrlf, safecrlf, reset HEAD' '
|
|
|
|
git config core.autocrlf false &&
|
|
|
|
git config core.safecrlf false &&
|
|
|
|
git reset --hard HEAD^
|
|
|
|
'
|
|
|
|
|
2007-02-14 22:54:00 +00:00
|
|
|
test_expect_success 'update with autocrlf=input' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf input &&
|
2015-03-25 05:28:44 +00:00
|
|
|
munge_cr append one &&
|
|
|
|
munge_cr append dir/two &&
|
|
|
|
git update-index -- one dir/two &&
|
2014-04-28 12:57:26 +00:00
|
|
|
differs=$(git diff-index --cached HEAD) &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test -z "$differs"
|
2007-02-14 22:54:00 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'update with autocrlf=true' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf true &&
|
2015-03-25 05:28:44 +00:00
|
|
|
munge_cr append one &&
|
|
|
|
munge_cr append dir/two &&
|
|
|
|
git update-index -- one dir/two &&
|
2014-04-28 12:57:26 +00:00
|
|
|
differs=$(git diff-index --cached HEAD) &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test -z "$differs"
|
2007-02-14 22:54:00 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'checkout with autocrlf=true' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf true &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
2015-03-25 05:28:44 +00:00
|
|
|
munge_cr remove one &&
|
|
|
|
munge_cr remove dir/two &&
|
|
|
|
git update-index -- one dir/two &&
|
2014-04-28 12:57:26 +00:00
|
|
|
test "$one" = $(git hash-object --stdin <one) &&
|
|
|
|
test "$two" = $(git hash-object --stdin <dir/two) &&
|
|
|
|
differs=$(git diff-index --cached HEAD) &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test -z "$differs"
|
2007-02-14 22:54:00 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'checkout with autocrlf=input' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf input &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
2019-12-20 18:15:53 +00:00
|
|
|
! has_cr one &&
|
|
|
|
! has_cr dir/two &&
|
2015-03-25 05:28:44 +00:00
|
|
|
git update-index -- one dir/two &&
|
2014-04-28 12:57:26 +00:00
|
|
|
test "$one" = $(git hash-object --stdin <one) &&
|
|
|
|
test "$two" = $(git hash-object --stdin <dir/two) &&
|
|
|
|
differs=$(git diff-index --cached HEAD) &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test -z "$differs"
|
2007-02-14 22:54:00 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'apply patch (autocrlf=input)' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf input &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
|
|
|
git apply patch.file &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test "$patched" = "$(git hash-object --stdin <one)"
|
2007-02-14 22:54:00 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'apply patch --cached (autocrlf=input)' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf input &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
|
|
|
git apply --cached patch.file &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test "$patched" = $(git rev-parse :one)
|
2007-02-14 22:54:00 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'apply patch --index (autocrlf=input)' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf input &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
|
|
|
git apply --index patch.file &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test "$patched" = $(git rev-parse :one) &&
|
|
|
|
test "$patched" = $(git hash-object --stdin <one)
|
2007-02-14 22:54:00 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'apply patch (autocrlf=true)' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf true &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
|
|
|
git apply patch.file &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test "$patched" = "$(remove_cr <one | git hash-object --stdin)"
|
2007-02-14 22:54:00 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'apply patch --cached (autocrlf=true)' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf true &&
|
2007-02-14 22:54:00 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
|
|
|
git apply --cached patch.file &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test "$patched" = $(git rev-parse :one)
|
2007-02-14 22:54:00 +00:00
|
|
|
'
|
|
|
|
|
2007-02-17 20:37:25 +00:00
|
|
|
test_expect_success 'apply patch --index (autocrlf=true)' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf true &&
|
2007-02-17 20:37:25 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
|
|
|
git apply --index patch.file &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
test "$patched" = $(git rev-parse :one) &&
|
|
|
|
test "$patched" = "$(remove_cr <one | git hash-object --stdin)"
|
2007-02-17 20:37:25 +00:00
|
|
|
'
|
|
|
|
|
2007-04-13 05:30:05 +00:00
|
|
|
test_expect_success '.gitattributes says two is binary' '
|
|
|
|
|
2007-04-20 05:37:19 +00:00
|
|
|
rm -f tmp one dir/two three &&
|
2007-04-15 21:56:09 +00:00
|
|
|
echo "two -crlf" >.gitattributes &&
|
2008-01-18 06:52:40 +00:00
|
|
|
git config core.autocrlf true &&
|
2007-04-13 05:30:05 +00:00
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
2019-12-20 18:15:53 +00:00
|
|
|
! has_cr dir/two &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
has_cr one &&
|
2019-12-20 18:15:53 +00:00
|
|
|
! has_cr three
|
2007-04-20 05:37:19 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '.gitattributes says two is input' '
|
|
|
|
|
|
|
|
rm -f tmp one dir/two three &&
|
|
|
|
echo "two crlf=input" >.gitattributes &&
|
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
2019-12-20 18:15:53 +00:00
|
|
|
! has_cr dir/two
|
2007-04-20 05:37:19 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '.gitattributes says two and three are text' '
|
|
|
|
|
|
|
|
rm -f tmp one dir/two three &&
|
|
|
|
echo "t* crlf" >.gitattributes &&
|
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
has_cr dir/two &&
|
|
|
|
has_cr three
|
2007-04-13 05:30:05 +00:00
|
|
|
'
|
|
|
|
|
2007-08-14 08:41:02 +00:00
|
|
|
test_expect_success 'in-tree .gitattributes (1)' '
|
|
|
|
|
|
|
|
echo "one -crlf" >>.gitattributes &&
|
|
|
|
git add .gitattributes &&
|
|
|
|
git commit -m "Add .gitattributes" &&
|
|
|
|
|
|
|
|
rm -rf tmp one dir .gitattributes patch.file three &&
|
|
|
|
git read-tree --reset -u HEAD &&
|
|
|
|
|
2019-12-20 18:15:53 +00:00
|
|
|
! has_cr one &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
has_cr three
|
2007-08-14 08:41:02 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'in-tree .gitattributes (2)' '
|
|
|
|
|
|
|
|
rm -rf tmp one dir .gitattributes patch.file three &&
|
|
|
|
git read-tree --reset HEAD &&
|
|
|
|
git checkout-index -f -q -u -a &&
|
|
|
|
|
2019-12-20 18:15:53 +00:00
|
|
|
! has_cr one &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
has_cr three
|
2007-08-14 08:41:02 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'in-tree .gitattributes (3)' '
|
|
|
|
|
|
|
|
rm -rf tmp one dir .gitattributes patch.file three &&
|
|
|
|
git read-tree --reset HEAD &&
|
|
|
|
git checkout-index -u .gitattributes &&
|
|
|
|
git checkout-index -u one dir/two three &&
|
|
|
|
|
2019-12-20 18:15:53 +00:00
|
|
|
! has_cr one &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
has_cr three
|
2007-08-14 08:41:02 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'in-tree .gitattributes (4)' '
|
|
|
|
|
|
|
|
rm -rf tmp one dir .gitattributes patch.file three &&
|
|
|
|
git read-tree --reset HEAD &&
|
|
|
|
git checkout-index -u one dir/two three &&
|
|
|
|
git checkout-index -u .gitattributes &&
|
|
|
|
|
2019-12-20 18:15:53 +00:00
|
|
|
! has_cr one &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
has_cr three
|
2007-08-14 08:41:02 +00:00
|
|
|
'
|
|
|
|
|
2009-03-20 09:32:09 +00:00
|
|
|
test_expect_success 'checkout with existing .gitattributes' '
|
|
|
|
|
|
|
|
git config core.autocrlf true &&
|
|
|
|
git config --unset core.safecrlf &&
|
|
|
|
echo ".file2 -crlfQ" | q_to_cr >> .gitattributes &&
|
|
|
|
git add .gitattributes &&
|
|
|
|
git commit -m initial &&
|
|
|
|
echo ".file -crlfQ" | q_to_cr >> .gitattributes &&
|
|
|
|
echo "contents" > .file &&
|
|
|
|
git add .gitattributes .file &&
|
|
|
|
git commit -m second &&
|
|
|
|
|
2020-11-18 23:44:21 +00:00
|
|
|
git checkout main~1 &&
|
|
|
|
git checkout main &&
|
2009-03-20 09:32:09 +00:00
|
|
|
test "$(git diff-files --raw)" = ""
|
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'checkout when deleting .gitattributes' '
|
|
|
|
|
|
|
|
git rm .gitattributes &&
|
|
|
|
echo "contentsQ" | q_to_cr > .file2 &&
|
|
|
|
git add .file2 &&
|
2010-10-31 07:30:58 +00:00
|
|
|
git commit -m third &&
|
2009-03-20 09:32:09 +00:00
|
|
|
|
2020-11-18 23:44:21 +00:00
|
|
|
git checkout main~1 &&
|
|
|
|
git checkout main &&
|
2010-01-26 00:33:57 +00:00
|
|
|
has_cr .file2
|
2009-03-20 09:32:09 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2007-10-18 20:02:35 +00:00
|
|
|
test_expect_success 'invalid .gitattributes (must not crash)' '
|
|
|
|
|
|
|
|
echo "three +crlf" >>.gitattributes &&
|
|
|
|
git diff
|
|
|
|
|
|
|
|
'
|
autocrlf: Make it work also for un-normalized repositories
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-05-11 22:37:57 +00:00
|
|
|
# Some more tests here to add new autocrlf functionality.
|
|
|
|
# We want to have a known state here, so start a bit from scratch
|
|
|
|
|
|
|
|
test_expect_success 'setting up for new autocrlf tests' '
|
|
|
|
git config core.autocrlf false &&
|
|
|
|
git config core.safecrlf false &&
|
|
|
|
rm -rf .????* * &&
|
2021-12-09 05:11:05 +00:00
|
|
|
test_write_lines I am all LF >alllf &&
|
|
|
|
test_write_lines Oh here is CRLFQ in text | q_to_cr >mixed &&
|
|
|
|
test_write_lines I am all CRLF | append_cr >allcrlf &&
|
autocrlf: Make it work also for un-normalized repositories
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-05-11 22:37:57 +00:00
|
|
|
git add -A . &&
|
|
|
|
git commit -m "alllf, allcrlf and mixed only" &&
|
|
|
|
git tag -a -m "message" autocrlf-checkpoint
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'report no change after setting autocrlf' '
|
|
|
|
git config core.autocrlf true &&
|
|
|
|
touch * &&
|
|
|
|
git diff --exit-code
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'files are clean after checkout' '
|
|
|
|
rm * &&
|
|
|
|
git checkout -f &&
|
|
|
|
git diff --exit-code
|
|
|
|
'
|
|
|
|
|
|
|
|
cr_to_Q_no_NL () {
|
|
|
|
tr '\015' Q | tr -d '\012'
|
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success 'LF only file gets CRLF with autocrlf' '
|
|
|
|
test "$(cr_to_Q_no_NL < alllf)" = "IQamQallQLFQ"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'Mixed file is still mixed with autocrlf' '
|
|
|
|
test "$(cr_to_Q_no_NL < mixed)" = "OhhereisCRLFQintext"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'CRLF only file has CRLF with autocrlf' '
|
|
|
|
test "$(cr_to_Q_no_NL < allcrlf)" = "IQamQallQCRLFQ"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'New CRLF file gets LF in repo' '
|
|
|
|
tr -d "\015" < alllf | append_cr > alllf2 &&
|
|
|
|
git add alllf2 &&
|
|
|
|
git commit -m "alllf2 added" &&
|
|
|
|
git config core.autocrlf false &&
|
|
|
|
rm * &&
|
|
|
|
git checkout -f &&
|
|
|
|
test_cmp alllf alllf2
|
|
|
|
'
|
2007-10-18 20:02:35 +00:00
|
|
|
|
2007-02-14 22:54:00 +00:00
|
|
|
test_done
|