2010-07-02 21:20:47 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
2010-08-05 13:09:33 +02:00
|
|
|
test_description='CRLF merge conflict across text=auto change
|
|
|
|
|
2020-11-19 00:44:38 +01:00
|
|
|
* [main] remove .gitattributes
|
2010-08-05 13:09:33 +02:00
|
|
|
! [side] add line from b
|
|
|
|
--
|
|
|
|
+ [side] add line from b
|
2020-11-19 00:44:38 +01:00
|
|
|
* [main] remove .gitattributes
|
|
|
|
* [main^] add line from a
|
|
|
|
* [main~2] normalize file
|
2010-08-05 13:09:33 +02:00
|
|
|
*+ [side^] Initial
|
|
|
|
'
|
2010-07-02 21:20:47 +02:00
|
|
|
|
2020-11-19 00:44:38 +01: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-19 00:44:19 +01:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2010-07-02 21:20:47 +02:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
2010-12-14 19:32:12 +01:00
|
|
|
test_have_prereq SED_STRIPS_CR && SED_OPTIONS=-b
|
2010-09-17 15:16:01 +02:00
|
|
|
|
2016-06-28 10:01:13 +02:00
|
|
|
compare_files () {
|
|
|
|
tr '\015\000' QN <"$1" >"$1".expect &&
|
|
|
|
tr '\015\000' QN <"$2" >"$2".actual &&
|
|
|
|
test_cmp "$1".expect "$2".actual &&
|
|
|
|
rm "$1".expect "$2".actual
|
|
|
|
}
|
|
|
|
|
2010-07-02 21:20:47 +02:00
|
|
|
test_expect_success setup '
|
|
|
|
git config core.autocrlf false &&
|
2010-08-05 13:09:33 +02:00
|
|
|
|
2010-07-02 21:20:47 +02:00
|
|
|
echo first line | append_cr >file &&
|
|
|
|
echo first line >control_file &&
|
|
|
|
echo only line >inert_file &&
|
2010-08-05 13:09:33 +02:00
|
|
|
|
2010-07-02 21:20:47 +02:00
|
|
|
git add file control_file inert_file &&
|
2010-08-05 13:09:33 +02:00
|
|
|
test_tick &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git commit -m "Initial" &&
|
|
|
|
git tag initial &&
|
|
|
|
git branch side &&
|
2010-08-05 13:09:33 +02:00
|
|
|
|
2010-07-02 21:20:47 +02:00
|
|
|
echo "* text=auto" >.gitattributes &&
|
2016-06-28 10:01:13 +02:00
|
|
|
echo first line >file &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git add .gitattributes file &&
|
2010-08-05 13:09:33 +02:00
|
|
|
test_tick &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git commit -m "normalize file" &&
|
2010-08-05 13:09:33 +02:00
|
|
|
|
2010-07-02 21:20:47 +02:00
|
|
|
echo same line | append_cr >>file &&
|
|
|
|
echo same line >>control_file &&
|
|
|
|
git add file control_file &&
|
2010-08-05 13:09:33 +02:00
|
|
|
test_tick &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git commit -m "add line from a" &&
|
|
|
|
git tag a &&
|
2010-08-05 13:09:33 +02:00
|
|
|
|
2010-07-02 21:20:47 +02:00
|
|
|
git rm .gitattributes &&
|
|
|
|
rm file &&
|
|
|
|
git checkout file &&
|
2010-08-05 13:09:33 +02:00
|
|
|
test_tick &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git commit -m "remove .gitattributes" &&
|
|
|
|
git tag c &&
|
2010-08-05 13:09:33 +02:00
|
|
|
|
2010-07-02 21:20:47 +02:00
|
|
|
git checkout side &&
|
|
|
|
echo same line | append_cr >>file &&
|
|
|
|
echo same line >>control_file &&
|
|
|
|
git add file control_file &&
|
2010-08-05 13:09:33 +02:00
|
|
|
test_tick &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git commit -m "add line from b" &&
|
|
|
|
git tag b &&
|
2010-08-05 13:09:33 +02:00
|
|
|
|
2020-11-19 00:44:38 +01:00
|
|
|
git checkout main
|
2010-07-02 21:20:47 +02:00
|
|
|
'
|
|
|
|
|
2010-08-05 13:13:04 +02:00
|
|
|
test_expect_success 'set up fuzz_conflict() helper' '
|
|
|
|
fuzz_conflict() {
|
2010-09-17 15:16:01 +02:00
|
|
|
sed $SED_OPTIONS -e "s/^\([<>=]......\) .*/\1/" "$@"
|
2010-08-05 13:13:04 +02:00
|
|
|
}
|
|
|
|
'
|
|
|
|
|
2010-08-05 13:09:33 +02:00
|
|
|
test_expect_success 'Merge after setting text=auto' '
|
|
|
|
cat <<-\EOF >expected &&
|
|
|
|
first line
|
|
|
|
same line
|
|
|
|
EOF
|
|
|
|
|
2014-08-30 23:39:07 +02:00
|
|
|
if test_have_prereq NATIVE_CRLF; then
|
|
|
|
append_cr <expected >expected.temp &&
|
|
|
|
mv expected.temp expected
|
|
|
|
fi &&
|
2010-08-05 13:13:04 +02:00
|
|
|
git config merge.renormalize true &&
|
2010-08-05 13:09:33 +02:00
|
|
|
git rm -fr . &&
|
|
|
|
rm -f .gitattributes &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git reset --hard a &&
|
|
|
|
git merge b &&
|
2016-06-28 10:01:13 +02:00
|
|
|
compare_files expected file
|
2010-07-02 21:20:47 +02:00
|
|
|
'
|
|
|
|
|
merge: avoid "safer crlf" during recording of merge results
When merge_recursive() decides what the correct blob object merge
result for a path should be, it uses update_file_flags() helper
function to write it out to a working tree file and then calls
add_cacheinfo(). The add_cacheinfo() function in turn calls
make_cache_entry() to create a new cache entry to replace the
higher-stage entries for the path that represents the conflict.
The make_cache_entry() function calls refresh_cache_entry() to fill
in the cached stat information. To mark a cache entry as
up-to-date, the data is re-read from the file in the working tree,
and goes through convert_to_git() conversion to be compared with the
blob object name the new cache entry records.
It is important to note that this happens while the higher-stage
entries, which are going to be replaced with the new entry, are
still in the index. Unfortunately, the convert_to_git() conversion
has a misguided "safer crlf" mechanism baked in, and looks at the
existing cache entry for the path to decide how to convert the
contents in the working tree file. If our side (i.e. stage#2)
records a text blob with CRLF in it, even when the system is
configured to record LF in blobs and convert them to CRLF upon
checkout (and back to LF upon checkin), the "safer crlf" mechanism
stops us doing so.
This especially poses a problem during a renormalizing merge, where
the merge result for the path is computed by first "normalizing" the
blobs involved in the merge by using convert_to_working_tree()
followed by convert_to_git() with "safer crlf" disabled. The merge
result that is computed correctly and fed to add_cacheinfo() via
update_file_flags() does _not_ match what refresh_cache_entry() sees
by converting the working tree file via convert_to_git().
We can work this around by not refreshing the new cache entry in
make_cache_entry() called by add_cacheinfo(). After add_cacheinfo()
adds the new entry, we can call refresh_cache_entry() on that,
knowing that addition of this new cache entry would have removed the
stale cache entries that had CRLF in stage #2 that were carried over
before the renormalizing merge started and will not interfere with
the correct recording of the result.
The test update was taken from a series by Torsten Bögershausen
that attempted to fix this with a different approach.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Torsten Bögershausen <tboegi@web.de>
2016-07-08 19:59:15 +02:00
|
|
|
test_expect_success 'Merge addition of text=auto eol=LF' '
|
|
|
|
git config core.eol lf &&
|
2010-08-05 13:09:33 +02:00
|
|
|
cat <<-\EOF >expected &&
|
|
|
|
first line
|
|
|
|
same line
|
|
|
|
EOF
|
|
|
|
|
2010-08-05 13:13:04 +02:00
|
|
|
git config merge.renormalize true &&
|
2010-08-05 13:09:33 +02:00
|
|
|
git rm -fr . &&
|
|
|
|
rm -f .gitattributes &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git reset --hard b &&
|
|
|
|
git merge a &&
|
2016-06-28 10:01:13 +02:00
|
|
|
compare_files expected file
|
2010-07-02 21:20:47 +02:00
|
|
|
'
|
|
|
|
|
merge: avoid "safer crlf" during recording of merge results
When merge_recursive() decides what the correct blob object merge
result for a path should be, it uses update_file_flags() helper
function to write it out to a working tree file and then calls
add_cacheinfo(). The add_cacheinfo() function in turn calls
make_cache_entry() to create a new cache entry to replace the
higher-stage entries for the path that represents the conflict.
The make_cache_entry() function calls refresh_cache_entry() to fill
in the cached stat information. To mark a cache entry as
up-to-date, the data is re-read from the file in the working tree,
and goes through convert_to_git() conversion to be compared with the
blob object name the new cache entry records.
It is important to note that this happens while the higher-stage
entries, which are going to be replaced with the new entry, are
still in the index. Unfortunately, the convert_to_git() conversion
has a misguided "safer crlf" mechanism baked in, and looks at the
existing cache entry for the path to decide how to convert the
contents in the working tree file. If our side (i.e. stage#2)
records a text blob with CRLF in it, even when the system is
configured to record LF in blobs and convert them to CRLF upon
checkout (and back to LF upon checkin), the "safer crlf" mechanism
stops us doing so.
This especially poses a problem during a renormalizing merge, where
the merge result for the path is computed by first "normalizing" the
blobs involved in the merge by using convert_to_working_tree()
followed by convert_to_git() with "safer crlf" disabled. The merge
result that is computed correctly and fed to add_cacheinfo() via
update_file_flags() does _not_ match what refresh_cache_entry() sees
by converting the working tree file via convert_to_git().
We can work this around by not refreshing the new cache entry in
make_cache_entry() called by add_cacheinfo(). After add_cacheinfo()
adds the new entry, we can call refresh_cache_entry() on that,
knowing that addition of this new cache entry would have removed the
stale cache entries that had CRLF in stage #2 that were carried over
before the renormalizing merge started and will not interfere with
the correct recording of the result.
The test update was taken from a series by Torsten Bögershausen
that attempted to fix this with a different approach.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Torsten Bögershausen <tboegi@web.de>
2016-07-08 19:59:15 +02:00
|
|
|
test_expect_success 'Merge addition of text=auto eol=CRLF' '
|
|
|
|
git config core.eol crlf &&
|
|
|
|
cat <<-\EOF >expected &&
|
|
|
|
first line
|
|
|
|
same line
|
|
|
|
EOF
|
|
|
|
|
|
|
|
append_cr <expected >expected.temp &&
|
|
|
|
mv expected.temp expected &&
|
|
|
|
git config merge.renormalize true &&
|
|
|
|
git rm -fr . &&
|
|
|
|
rm -f .gitattributes &&
|
|
|
|
git reset --hard b &&
|
|
|
|
echo >&2 "After git reset --hard b" &&
|
|
|
|
git ls-files -s --eol >&2 &&
|
|
|
|
git merge a &&
|
|
|
|
compare_files expected file
|
|
|
|
'
|
|
|
|
|
2010-08-05 13:13:04 +02:00
|
|
|
test_expect_success 'Detect CRLF/LF conflict after setting text=auto' '
|
merge: avoid "safer crlf" during recording of merge results
When merge_recursive() decides what the correct blob object merge
result for a path should be, it uses update_file_flags() helper
function to write it out to a working tree file and then calls
add_cacheinfo(). The add_cacheinfo() function in turn calls
make_cache_entry() to create a new cache entry to replace the
higher-stage entries for the path that represents the conflict.
The make_cache_entry() function calls refresh_cache_entry() to fill
in the cached stat information. To mark a cache entry as
up-to-date, the data is re-read from the file in the working tree,
and goes through convert_to_git() conversion to be compared with the
blob object name the new cache entry records.
It is important to note that this happens while the higher-stage
entries, which are going to be replaced with the new entry, are
still in the index. Unfortunately, the convert_to_git() conversion
has a misguided "safer crlf" mechanism baked in, and looks at the
existing cache entry for the path to decide how to convert the
contents in the working tree file. If our side (i.e. stage#2)
records a text blob with CRLF in it, even when the system is
configured to record LF in blobs and convert them to CRLF upon
checkout (and back to LF upon checkin), the "safer crlf" mechanism
stops us doing so.
This especially poses a problem during a renormalizing merge, where
the merge result for the path is computed by first "normalizing" the
blobs involved in the merge by using convert_to_working_tree()
followed by convert_to_git() with "safer crlf" disabled. The merge
result that is computed correctly and fed to add_cacheinfo() via
update_file_flags() does _not_ match what refresh_cache_entry() sees
by converting the working tree file via convert_to_git().
We can work this around by not refreshing the new cache entry in
make_cache_entry() called by add_cacheinfo(). After add_cacheinfo()
adds the new entry, we can call refresh_cache_entry() on that,
knowing that addition of this new cache entry would have removed the
stale cache entries that had CRLF in stage #2 that were carried over
before the renormalizing merge started and will not interfere with
the correct recording of the result.
The test update was taken from a series by Torsten Bögershausen
that attempted to fix this with a different approach.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Torsten Bögershausen <tboegi@web.de>
2016-07-08 19:59:15 +02:00
|
|
|
git config core.eol native &&
|
2014-08-30 23:39:07 +02:00
|
|
|
echo "<<<<<<<" >expected &&
|
merge: avoid "safer crlf" during recording of merge results
When merge_recursive() decides what the correct blob object merge
result for a path should be, it uses update_file_flags() helper
function to write it out to a working tree file and then calls
add_cacheinfo(). The add_cacheinfo() function in turn calls
make_cache_entry() to create a new cache entry to replace the
higher-stage entries for the path that represents the conflict.
The make_cache_entry() function calls refresh_cache_entry() to fill
in the cached stat information. To mark a cache entry as
up-to-date, the data is re-read from the file in the working tree,
and goes through convert_to_git() conversion to be compared with the
blob object name the new cache entry records.
It is important to note that this happens while the higher-stage
entries, which are going to be replaced with the new entry, are
still in the index. Unfortunately, the convert_to_git() conversion
has a misguided "safer crlf" mechanism baked in, and looks at the
existing cache entry for the path to decide how to convert the
contents in the working tree file. If our side (i.e. stage#2)
records a text blob with CRLF in it, even when the system is
configured to record LF in blobs and convert them to CRLF upon
checkout (and back to LF upon checkin), the "safer crlf" mechanism
stops us doing so.
This especially poses a problem during a renormalizing merge, where
the merge result for the path is computed by first "normalizing" the
blobs involved in the merge by using convert_to_working_tree()
followed by convert_to_git() with "safer crlf" disabled. The merge
result that is computed correctly and fed to add_cacheinfo() via
update_file_flags() does _not_ match what refresh_cache_entry() sees
by converting the working tree file via convert_to_git().
We can work this around by not refreshing the new cache entry in
make_cache_entry() called by add_cacheinfo(). After add_cacheinfo()
adds the new entry, we can call refresh_cache_entry() on that,
knowing that addition of this new cache entry would have removed the
stale cache entries that had CRLF in stage #2 that were carried over
before the renormalizing merge started and will not interfere with
the correct recording of the result.
The test update was taken from a series by Torsten Bögershausen
that attempted to fix this with a different approach.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Torsten Bögershausen <tboegi@web.de>
2016-07-08 19:59:15 +02:00
|
|
|
echo first line >>expected &&
|
|
|
|
echo same line >>expected &&
|
|
|
|
echo ======= >>expected &&
|
2014-08-30 23:39:07 +02:00
|
|
|
echo first line | append_cr >>expected &&
|
|
|
|
echo same line | append_cr >>expected &&
|
|
|
|
echo ">>>>>>>" >>expected &&
|
2010-08-05 13:13:04 +02:00
|
|
|
git config merge.renormalize false &&
|
|
|
|
rm -f .gitattributes &&
|
|
|
|
git reset --hard a &&
|
|
|
|
test_must_fail git merge b &&
|
|
|
|
fuzz_conflict file >file.fuzzy &&
|
2016-06-28 10:01:13 +02:00
|
|
|
compare_files expected file.fuzzy
|
2010-08-05 13:13:04 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'Detect LF/CRLF conflict from addition of text=auto' '
|
2014-08-30 23:39:07 +02:00
|
|
|
echo "<<<<<<<" >expected &&
|
|
|
|
echo first line | append_cr >>expected &&
|
|
|
|
echo same line | append_cr >>expected &&
|
merge: avoid "safer crlf" during recording of merge results
When merge_recursive() decides what the correct blob object merge
result for a path should be, it uses update_file_flags() helper
function to write it out to a working tree file and then calls
add_cacheinfo(). The add_cacheinfo() function in turn calls
make_cache_entry() to create a new cache entry to replace the
higher-stage entries for the path that represents the conflict.
The make_cache_entry() function calls refresh_cache_entry() to fill
in the cached stat information. To mark a cache entry as
up-to-date, the data is re-read from the file in the working tree,
and goes through convert_to_git() conversion to be compared with the
blob object name the new cache entry records.
It is important to note that this happens while the higher-stage
entries, which are going to be replaced with the new entry, are
still in the index. Unfortunately, the convert_to_git() conversion
has a misguided "safer crlf" mechanism baked in, and looks at the
existing cache entry for the path to decide how to convert the
contents in the working tree file. If our side (i.e. stage#2)
records a text blob with CRLF in it, even when the system is
configured to record LF in blobs and convert them to CRLF upon
checkout (and back to LF upon checkin), the "safer crlf" mechanism
stops us doing so.
This especially poses a problem during a renormalizing merge, where
the merge result for the path is computed by first "normalizing" the
blobs involved in the merge by using convert_to_working_tree()
followed by convert_to_git() with "safer crlf" disabled. The merge
result that is computed correctly and fed to add_cacheinfo() via
update_file_flags() does _not_ match what refresh_cache_entry() sees
by converting the working tree file via convert_to_git().
We can work this around by not refreshing the new cache entry in
make_cache_entry() called by add_cacheinfo(). After add_cacheinfo()
adds the new entry, we can call refresh_cache_entry() on that,
knowing that addition of this new cache entry would have removed the
stale cache entries that had CRLF in stage #2 that were carried over
before the renormalizing merge started and will not interfere with
the correct recording of the result.
The test update was taken from a series by Torsten Bögershausen
that attempted to fix this with a different approach.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Torsten Bögershausen <tboegi@web.de>
2016-07-08 19:59:15 +02:00
|
|
|
echo ======= >>expected &&
|
|
|
|
echo first line >>expected &&
|
|
|
|
echo same line >>expected &&
|
2014-08-30 23:39:07 +02:00
|
|
|
echo ">>>>>>>" >>expected &&
|
2010-08-05 13:13:04 +02:00
|
|
|
git config merge.renormalize false &&
|
|
|
|
rm -f .gitattributes &&
|
|
|
|
git reset --hard b &&
|
|
|
|
test_must_fail git merge a &&
|
|
|
|
fuzz_conflict file >file.fuzzy &&
|
2016-06-28 10:01:13 +02:00
|
|
|
compare_files expected file.fuzzy
|
2010-08-05 13:13:04 +02:00
|
|
|
'
|
|
|
|
|
2020-08-03 20:41:19 +02:00
|
|
|
test_expect_success 'checkout -m after setting text=auto' '
|
2010-08-05 13:11:12 +02:00
|
|
|
cat <<-\EOF >expected &&
|
|
|
|
first line
|
|
|
|
same line
|
|
|
|
EOF
|
|
|
|
|
2010-08-05 13:13:04 +02:00
|
|
|
git config merge.renormalize true &&
|
2010-08-05 13:11:12 +02:00
|
|
|
git rm -fr . &&
|
|
|
|
rm -f .gitattributes &&
|
|
|
|
git reset --hard initial &&
|
t6038: make tests fail for the right reason
t6038 had a pair of tests that were expected to fail, but weren't
failing for the expected reason. Both were meant to do a merge that
could be done cleanly after renormalization, but were supposed to fail
for lack of renormalization. Unfortunately, both tests had staged
changes, and checkout -m would abort due to the presence of those staged
changes before even attempting a merge.
Fix this first issue by utilizing git-restore instead of git-checkout,
so that the index is left alone and just the working directory gets the
changes we want.
However, there is a second issue with these tests. Technically, they
just wanted to verify that after renormalization, no conflicts would be
present. This could have been checked for by grepping for a lack of
conflict markers, but the test instead tried to compare the working
directory files to an expected result. Unfortunately, the setting of
"text=auto" without setting core.eol to any value meant that the content
of the file (in particular, the line endings) would be
platform-dependent and the tests could only pass on some platforms.
Replace the existing comparison with a call to 'git diff --no-index
--ignore-cr-at-eol' to verify that the contents, other than possible
carriage returns in the file, match the expected results and in
particular that the file has no conflicts from the checkout -m
operation.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:41:17 +02:00
|
|
|
git restore --source=a -- . &&
|
2010-08-05 13:11:12 +02:00
|
|
|
git checkout -m b &&
|
t6038: make tests fail for the right reason
t6038 had a pair of tests that were expected to fail, but weren't
failing for the expected reason. Both were meant to do a merge that
could be done cleanly after renormalization, but were supposed to fail
for lack of renormalization. Unfortunately, both tests had staged
changes, and checkout -m would abort due to the presence of those staged
changes before even attempting a merge.
Fix this first issue by utilizing git-restore instead of git-checkout,
so that the index is left alone and just the working directory gets the
changes we want.
However, there is a second issue with these tests. Technically, they
just wanted to verify that after renormalization, no conflicts would be
present. This could have been checked for by grepping for a lack of
conflict markers, but the test instead tried to compare the working
directory files to an expected result. Unfortunately, the setting of
"text=auto" without setting core.eol to any value meant that the content
of the file (in particular, the line endings) would be
platform-dependent and the tests could only pass on some platforms.
Replace the existing comparison with a call to 'git diff --no-index
--ignore-cr-at-eol' to verify that the contents, other than possible
carriage returns in the file, match the expected results and in
particular that the file has no conflicts from the checkout -m
operation.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:41:17 +02:00
|
|
|
git diff --no-index --ignore-cr-at-eol expected file
|
2010-08-05 13:11:12 +02:00
|
|
|
'
|
|
|
|
|
2020-08-03 20:41:19 +02:00
|
|
|
test_expect_success 'checkout -m addition of text=auto' '
|
2010-08-05 13:11:12 +02:00
|
|
|
cat <<-\EOF >expected &&
|
|
|
|
first line
|
|
|
|
same line
|
|
|
|
EOF
|
|
|
|
|
2010-08-05 13:13:04 +02:00
|
|
|
git config merge.renormalize true &&
|
2010-08-05 13:11:12 +02:00
|
|
|
git rm -fr . &&
|
|
|
|
rm -f .gitattributes file &&
|
|
|
|
git reset --hard initial &&
|
t6038: make tests fail for the right reason
t6038 had a pair of tests that were expected to fail, but weren't
failing for the expected reason. Both were meant to do a merge that
could be done cleanly after renormalization, but were supposed to fail
for lack of renormalization. Unfortunately, both tests had staged
changes, and checkout -m would abort due to the presence of those staged
changes before even attempting a merge.
Fix this first issue by utilizing git-restore instead of git-checkout,
so that the index is left alone and just the working directory gets the
changes we want.
However, there is a second issue with these tests. Technically, they
just wanted to verify that after renormalization, no conflicts would be
present. This could have been checked for by grepping for a lack of
conflict markers, but the test instead tried to compare the working
directory files to an expected result. Unfortunately, the setting of
"text=auto" without setting core.eol to any value meant that the content
of the file (in particular, the line endings) would be
platform-dependent and the tests could only pass on some platforms.
Replace the existing comparison with a call to 'git diff --no-index
--ignore-cr-at-eol' to verify that the contents, other than possible
carriage returns in the file, match the expected results and in
particular that the file has no conflicts from the checkout -m
operation.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:41:17 +02:00
|
|
|
git restore --source=b -- . &&
|
2010-08-05 13:11:12 +02:00
|
|
|
git checkout -m a &&
|
t6038: make tests fail for the right reason
t6038 had a pair of tests that were expected to fail, but weren't
failing for the expected reason. Both were meant to do a merge that
could be done cleanly after renormalization, but were supposed to fail
for lack of renormalization. Unfortunately, both tests had staged
changes, and checkout -m would abort due to the presence of those staged
changes before even attempting a merge.
Fix this first issue by utilizing git-restore instead of git-checkout,
so that the index is left alone and just the working directory gets the
changes we want.
However, there is a second issue with these tests. Technically, they
just wanted to verify that after renormalization, no conflicts would be
present. This could have been checked for by grepping for a lack of
conflict markers, but the test instead tried to compare the working
directory files to an expected result. Unfortunately, the setting of
"text=auto" without setting core.eol to any value meant that the content
of the file (in particular, the line endings) would be
platform-dependent and the tests could only pass on some platforms.
Replace the existing comparison with a call to 'git diff --no-index
--ignore-cr-at-eol' to verify that the contents, other than possible
carriage returns in the file, match the expected results and in
particular that the file has no conflicts from the checkout -m
operation.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:41:17 +02:00
|
|
|
git diff --no-index --ignore-cr-at-eol expected file
|
2010-08-05 13:11:12 +02:00
|
|
|
'
|
|
|
|
|
2010-07-02 21:20:48 +02:00
|
|
|
test_expect_success 'Test delete/normalize conflict' '
|
2010-08-05 13:09:33 +02:00
|
|
|
git checkout -f side &&
|
|
|
|
git rm -fr . &&
|
|
|
|
rm -f .gitattributes &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git reset --hard initial &&
|
|
|
|
git rm file &&
|
|
|
|
git commit -m "remove file" &&
|
2020-11-19 00:44:38 +01:00
|
|
|
git checkout main &&
|
2010-07-02 21:20:47 +02:00
|
|
|
git reset --hard a^ &&
|
2020-08-11 00:29:10 +02:00
|
|
|
git merge side &&
|
|
|
|
test_path_is_missing file
|
2010-07-02 21:20:47 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_done
|