summaryrefslogtreecommitdiff
path: root/t/t6038-merge-text-auto.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-07-12merge: avoid "safer crlf" during recording of merge resultsLibravatar Junio C Hamano1-23/+28
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-06convert: unify the "auto" handling of CRLFLibravatar Torsten Bögershausen1-8/+15
Before this change, $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes would have the same effect as $ echo "* text" >.gitattributes $ git config core.eol crlf Since the 'eol' attribute had higher priority than 'text=auto', this may corrupt binary files and is not what most users expect to happen. Make the 'eol' attribute to obey 'text=auto' and now $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes behaves the same as $ echo "* text=auto" >.gitattributes $ git config core.eol crlf In other words, $ echo "* text=auto eol=crlf" >.gitattributes has the same effect as $ git config core.autocrlf true and $ echo "* text=auto eol=lf" >.gitattributes has the same effect as $ git config core.autocrlf input Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-02MinGW: update tests to handle a native eol of crlfLibravatar Brice Lambson1-20/+34
Some of the tests were written with the assumption that the native eol would always be lf. After defining NATIVE_CRLF on MinGW, these tests began failing. This change will update the tests to also handle a native eol of crlf. Signed-off-by: Brice Lambson <bricelam@live.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-08t6038-*.sh: Pass the -b (--binary) option to sed on cygwinLibravatar Ramsay Jones1-1/+1
The tests using the fuzz_conflict helper function (tests 5-6) fail on cygwin in the same way they used to on MinGW, prior to commit ca02ad3. The solution is also the same; passing the -b (--binary) option to sed, using the SED_OPTIONS variable. We introduce a new prerequisite SED_STRIPS_CR to use in the conditional initialisation of SED_OPTIONS, rather than MINGW. The new prerequisite is set in test-lib.sh for both MinGW and Cygwin. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-03Side-step sed line-ending "corruption" leading to t6038 failure.Libravatar Eric Sunshine1-1/+3
By default, MSYS sed throws away CR from CRLF line-endings. Tests t6038.5 and t6038.6 employ sed to normalize conflict output of git-merge for validation purposes. These tests expect CRLF line-endings to be present in the normalized output of git-merge, and thus fail when sed undesirably removes CR. Fix by employing sed's -b/--binary switch to suppress its default behavior of dropping CR characters. Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2010-08-06t6038 (merge.renormalize): check that it can be turned offLibravatar Jonathan Nieder1-1/+49
An unusual sort of person (not me) may even enjoy the conflicts from line-ending changes. But more importantly, it is useful to document that behavior so we can more easily notice if it changes in an uncontrolled way while no one is watching. Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06t6038 (merge.renormalize): try checkout -m and cherry-pickLibravatar Jonathan Nieder1-0/+41
checkout -m and cherry-pick have not been wired up to respect merge.renormalize, but a naïve user would not know that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06t6038 (merge.renormalize): style nitpicksLibravatar Jonathan Nieder1-8/+44
Some tweaks to simplify adding and running tests. - Use test_tick for predictable, sort of realistic commit dates; - Use test_cmp as "test_cmp expected actual" --- some crazy content that was not expected should cause the test to fail; - Remove and re-add all files at the start of each test so the worktree is easier to think about; - Avoid using cat where not necessary for clarity. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-02Try normalizing files to avoid delete/modify conflicts when mergingLibravatar Eyvind Bernhardsen1-1/+1
If a file is modified due to normalization on one branch, and deleted on another, a merge of the two branches will result in a delete/modify conflict for that file even if it is otherwise unchanged. Try to avoid the conflict by normalizing and comparing the "base" file and the modified file when their sha1s differ. If they compare equal, the file is considered unmodified and is deleted. Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-02Avoid conflicts when merging branches with mixed normalizationLibravatar Eyvind Bernhardsen1-0/+64
Currently, merging across changes in line ending normalization is painful since files containing CRLF will conflict with normalized files, even if the only difference between the two versions is the line endings. Additionally, any "real" merge conflicts that exist are obscured because every line in the file has a conflict. Assume you start out with a repo that has a lot of text files with CRLF checked in (A): o---C / \ A---B---D B: Add "* text=auto" to .gitattributes and normalize all files to LF-only C: Modify some of the text files D: Try to merge C You will get a ridiculous number of LF/CRLF conflicts when trying to merge C into D, since the repository contents for C are "wrong" wrt the new .gitattributes file. Fix ll-merge so that the "base", "theirs" and "ours" stages are passed through convert_to_worktree() and convert_to_git() before a three-way merge. This ensures that all three stages are normalized in the same way, removing from consideration differences that are only due to normalization. This feature is optional for now since it changes a low-level mechanism and is not necessary for the majority of users. The "merge.renormalize" config variable enables it. Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>