kernel/git - git - PowerEL Git System

Tree: 97f2c33a52

Author	SHA1	Message	Date
Jonathan Nieder	beeeb45493	t6038 (merge.renormalize): check that it can be turned off 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>	15 years ago
Jonathan Nieder	d347cee4de	t6038 (merge.renormalize): try checkout -m and cherry-pick 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>	15 years ago
Jonathan Nieder	18acb30ee4	t6038 (merge.renormalize): style nitpicks 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>	15 years ago
Eyvind Bernhardsen	331a1838b2	Try normalizing files to avoid delete/modify conflicts when merging 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>	15 years ago
Eyvind Bernhardsen	f217f0e86d	Avoid conflicts when merging branches with mixed normalization 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>	15 years ago