summaryrefslogtreecommitdiff
path: root/t/t6038-merge-text-auto.sh
AgeCommit message (Collapse)AuthorFilesLines
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>