git/t/t6427-diff3-conflict-markers.sh

212 lines
3.3 KiB
Bash
Raw Normal View History

merge-recursive: provide a better label for diff3 common ancestor In commit 7ca56aa07619 ("merge-recursive: add a label for ancestor", 2010-03-20), a label was added for the '||||||' line to make it have the more informative heading '|||||| merged common ancestors', with the statement: It would be nicer to use a more informative label. Perhaps someone will provide one some day. This chosen label was perfectly reasonable when recursiveness kicks in, i.e. when there are multiple merge bases. (I can't think of a better label in such cases.) But it is actually somewhat misleading when there is a unique merge base or no merge base. Change this based on the number of merge bases: >=2: "merged common ancestors" 1: <abbreviated commit hash> 0: "<empty tree>" Tests have also been added to check that we get the right ancestor name for each of the three cases. Also, since merge_recursive() and merge_trees() have polar opposite pre-conditions for opt->ancestor, document merge_recursive()'s pre-condition with an assertion. (An assertion was added to merge_trees() already a few commits ago.) The differences in pre-conditions stem from two factors: (1) merge_trees() does not recurse and thus does not have multiple sub-merges to worry about -- each of which would require a different value for opt->ancestor, (2) merge_trees() is only passed trees rather than commits and thus cannot internally guess as good of a label. Thus, while external callers of merge_trees() are required to provide a non-NULL opt->ancestor, merge_recursive() expects to set this value itself. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-18 02:41:24 +08:00
#!/bin/sh
test_description='recursive merge diff3 style conflict markers'
. ./test-lib.sh
# Setup:
# L1
# \
# ?
# /
# R1
#
# Where:
# L1 and R1 both have a file named 'content' but have no common history
#
test_expect_success 'setup no merge base' '
test_create_repo no_merge_base &&
(
cd no_merge_base &&
git checkout -b L &&
test_commit A content A &&
git checkout --orphan R &&
test_commit B content B
)
'
test_expect_success 'check no merge base' '
(
cd no_merge_base &&
git checkout L^0 &&
test_must_fail git -c merge.conflictstyle=diff3 merge --allow-unrelated-histories -s recursive R^0 &&
grep "|||||| empty tree" content
)
'
# Setup:
# L1
# / \
# master ?
# \ /
# R1
#
# Where:
# L1 and R1 have modified the same file ('content') in conflicting ways
#
test_expect_success 'setup unique merge base' '
test_create_repo unique_merge_base &&
(
cd unique_merge_base &&
test_commit base content "1
2
3
4
5
" &&
git branch L &&
git branch R &&
git checkout L &&
test_commit L content "1
2
3
4
5
7" &&
git checkout R &&
git rm content &&
test_commit R renamed "1
2
3
4
5
six"
)
'
test_expect_success 'check unique merge base' '
(
cd unique_merge_base &&
git checkout L^0 &&
MASTER=$(git rev-parse --short master) &&
test_must_fail git -c merge.conflictstyle=diff3 merge -s recursive R^0 &&
grep "|||||| $MASTER:content" renamed
)
'
# Setup:
# L1---L2--L3
# / \ / \
# master X1 ?
# \ / \ /
# R1---R2--R3
#
# Where:
# commits L1 and R1 have modified the same file in non-conflicting ways
# X1 is an auto-generated merge-base used when merging L1 and R1
# commits L2 and R2 are merges of R1 and L1 into L1 and R1, respectively
# commits L3 and R3 both modify 'content' in conflicting ways
#
test_expect_success 'setup multiple merge bases' '
test_create_repo multiple_merge_bases &&
(
cd multiple_merge_bases &&
test_commit initial content "1
2
3
4
5" &&
git branch L &&
git branch R &&
# Create L1
git checkout L &&
test_commit L1 content "0
1
2
3
4
5" &&
# Create R1
git checkout R &&
test_commit R1 content "1
2
3
4
5
6" &&
# Create L2
git checkout L &&
git merge R1 &&
# Create R2
git checkout R &&
git merge L1 &&
# Create L3
git checkout L &&
test_commit L3 content "0
1
2
3
4
5
A" &&
# Create R3
git checkout R &&
git rm content &&
test_commit R3 renamed "0
2
3
4
5
six"
)
'
test_expect_success 'check multiple merge bases' '
(
cd multiple_merge_bases &&
git checkout L^0 &&
test_must_fail git -c merge.conflictstyle=diff3 merge -s recursive R^0 &&
grep "|||||| merged common ancestors:content" renamed
)
'
test_expect_success 'rebase --merge describes parent of commit being picked' '
test_create_repo rebase &&
(
cd rebase &&
test_commit base file &&
test_commit master file &&
git checkout -b side HEAD^ &&
test_commit side file &&
test_must_fail git -c merge.conflictstyle=diff3 rebase --merge master &&
grep "||||||| parent of" file
)
'
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:41 +08:00
test_expect_success 'rebase --apply describes fake ancestor base' '
(
cd rebase &&
git rebase --abort &&
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:41 +08:00
test_must_fail git -c merge.conflictstyle=diff3 rebase --apply master &&
grep "||||||| constructed merge base" file
)
'
merge-recursive: provide a better label for diff3 common ancestor In commit 7ca56aa07619 ("merge-recursive: add a label for ancestor", 2010-03-20), a label was added for the '||||||' line to make it have the more informative heading '|||||| merged common ancestors', with the statement: It would be nicer to use a more informative label. Perhaps someone will provide one some day. This chosen label was perfectly reasonable when recursiveness kicks in, i.e. when there are multiple merge bases. (I can't think of a better label in such cases.) But it is actually somewhat misleading when there is a unique merge base or no merge base. Change this based on the number of merge bases: >=2: "merged common ancestors" 1: <abbreviated commit hash> 0: "<empty tree>" Tests have also been added to check that we get the right ancestor name for each of the three cases. Also, since merge_recursive() and merge_trees() have polar opposite pre-conditions for opt->ancestor, document merge_recursive()'s pre-condition with an assertion. (An assertion was added to merge_trees() already a few commits ago.) The differences in pre-conditions stem from two factors: (1) merge_trees() does not recurse and thus does not have multiple sub-merges to worry about -- each of which would require a different value for opt->ancestor, (2) merge_trees() is only passed trees rather than commits and thus cannot internally guess as good of a label. Thus, while external callers of merge_trees() are required to provide a non-NULL opt->ancestor, merge_recursive() expects to set this value itself. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-18 02:41:24 +08:00
test_done