merge-tree: implement real merges
This adds the ability to perform real merges rather than just trivial
merges (meaning handling three way content merges, recursive ancestor
consolidation, renames, proper directory/file conflict handling, and so
forth). However, unlike `git merge`, the working tree and index are
left alone and no branch is updated.
The only output is:
- the toplevel resulting tree printed on stdout
- exit status of 0 (clean), 1 (conflicts present), anything else
(merge could not be performed; unknown if clean or conflicted)
This output is meant to be used by some higher level script, perhaps in
a sequence of steps like this:
NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2)
test $? -eq 0 || die "There were conflicts..."
NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2)
git update-ref $BRANCH1 $NEWCOMMIT
Note that higher level scripts may also want to access the
conflict/warning messages normally output during a merge, or have quick
access to a list of files with conflicts. That is not available in this
preliminary implementation, but subsequent commits will add that
ability (meaning that NEWTREE would be a lot more than a tree in the
case of conflicts).
This also marks the traditional trivial merge of merge-tree as
deprecated. The trivial merge not only had limited applicability, the
output format was also difficult to work with (and its format
undocumented), and will generally be less performant than real merges.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
#!/bin/sh
test_description = 'git merge-tree --write-tree'
. ./test-lib.sh
# This test is ort-specific
if test " $GIT_TEST_MERGE_ALGORITHM " != "ort"
then
skip_all = "GIT_TEST_MERGE_ALGORITHM != ort"
test_done
fi
test_expect_success setup '
test_write_lines 1 2 3 4 5 >numbers &&
echo hello >greeting &&
echo foo >whatever &&
git add numbers greeting whatever &&
test_tick &&
git commit -m initial &&
git branch side1 &&
git branch side2 &&
git branch side3 &&
git checkout side1 &&
test_write_lines 1 2 3 4 5 6 >numbers &&
echo hi >greeting &&
echo bar >whatever &&
git add numbers greeting whatever &&
test_tick &&
git commit -m modify-stuff &&
git checkout side2 &&
test_write_lines 0 1 2 3 4 5 >numbers &&
echo yo >greeting &&
git rm whatever &&
mkdir whatever &&
>whatever/empty &&
git add numbers greeting whatever/empty &&
test_tick &&
git commit -m other-modifications &&
git checkout side3 &&
git mv numbers sequence &&
test_tick &&
git commit -m rename-numbers
'
test_expect_success 'Clean merge' '
TREE_OID = $( git merge-tree --write-tree side1 side3) &&
q_to_tab <<-EOF >expect &&
100644 blob $( git rev-parse side1:greeting) Qgreeting
100644 blob $( git rev-parse side1:numbers) Qsequence
100644 blob $( git rev-parse side1:whatever) Qwhatever
EOF
git ls-tree $TREE_OID >actual &&
test_cmp expect actual
'
test_expect_success 'Content merge and a few conflicts' '
git checkout side1^0 &&
test_must_fail git merge side2 &&
expected_tree = $( git rev-parse AUTO_MERGE) &&
# We will redo the merge, while we are still in a conflicted state!
2022-06-18 02:20:53 +02:00
git ls-files -u >conflicted-file-info &&
merge-tree: implement real merges
This adds the ability to perform real merges rather than just trivial
merges (meaning handling three way content merges, recursive ancestor
consolidation, renames, proper directory/file conflict handling, and so
forth). However, unlike `git merge`, the working tree and index are
left alone and no branch is updated.
The only output is:
- the toplevel resulting tree printed on stdout
- exit status of 0 (clean), 1 (conflicts present), anything else
(merge could not be performed; unknown if clean or conflicted)
This output is meant to be used by some higher level script, perhaps in
a sequence of steps like this:
NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2)
test $? -eq 0 || die "There were conflicts..."
NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2)
git update-ref $BRANCH1 $NEWCOMMIT
Note that higher level scripts may also want to access the
conflict/warning messages normally output during a merge, or have quick
access to a list of files with conflicts. That is not available in this
preliminary implementation, but subsequent commits will add that
ability (meaning that NEWTREE would be a lot more than a tree in the
case of conflicts).
This also marks the traditional trivial merge of merge-tree as
deprecated. The trivial merge not only had limited applicability, the
output format was also difficult to work with (and its format
undocumented), and will generally be less performant than real merges.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
test_when_finished "git reset --hard" &&
test_expect_code 1 git merge-tree --write-tree side1 side2 >RESULT &&
actual_tree = $( head -n 1 RESULT) &&
# Due to differences of e.g. "HEAD" vs "side1", the results will not
# exactly match. Dig into individual files.
# Numbers should have three-way merged cleanly
test_write_lines 0 1 2 3 4 5 6 >expect &&
git show ${ actual_tree } :numbers >actual &&
test_cmp expect actual &&
# whatever and whatever~<branch> should have same HASHES
git rev-parse ${ expected_tree } :whatever ${ expected_tree } :whatever~HEAD >expect &&
git rev-parse ${ actual_tree } :whatever ${ actual_tree } :whatever~side1 >actual &&
test_cmp expect actual &&
# greeting should have a merge conflict
git show ${ expected_tree } :greeting >tmp &&
sed -e s/HEAD/side1/ tmp >expect &&
git show ${ actual_tree } :greeting >actual &&
test_cmp expect actual
'
test_expect_success 'Barf on misspelled option, with exit code other than 0 or 1' '
# Mis-spell with single "s" instead of double "s"
test_expect_code 129 git merge-tree --write-tree --mesages FOOBAR side1 side2 2>expect &&
grep "error: unknown option.*mesages" expect
'
test_expect_success 'Barf on too many arguments' '
test_expect_code 129 git merge-tree --write-tree side1 side2 invalid 2>expect &&
grep "^usage: git merge-tree" expect
'
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:49 +02:00
anonymize_hash( ) {
sed -e "s/[0-9a-f]\{40,\}/HASH/g" " $@ "
}
test_expect_success 'test conflict notices and such' '
2022-06-18 02:20:53 +02:00
test_expect_code 1 git merge-tree --write-tree --name-only side1 side2 >out &&
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:49 +02:00
anonymize_hash out >actual &&
# Expected results:
# "greeting" should merge with conflicts
# "numbers" should merge cleanly
# "whatever" has *both* a modify/delete and a file/directory conflict
cat <<-EOF >expect &&
HASH
2022-06-18 02:20:52 +02:00
greeting
whatever~side1
merge-tree: support including merge messages in output
When running `git merge-tree --write-tree`, we previously would only
return an exit status reflecting the cleanness of a merge, and print out
the toplevel tree of the resulting merge. Merges also have
informational messages, such as:
* "Auto-merging <PATH>"
* "CONFLICT (content): ..."
* "CONFLICT (file/directory)"
* etc.
In fact, when non-content conflicts occur (such as file/directory,
modify/delete, add/add with differing modes, rename/rename (1to2),
etc.), these informational messages may be the only notification the
user gets since these conflicts are not representable in the contents
of the file.
Add a --[no-]messages option so that callers can request these messages
be included at the end of the output. Include such messages by default
when there are conflicts, and omit them by default when the merge is
clean.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:49 +02:00
Auto-merging greeting
CONFLICT ( content) : Merge conflict in greeting
Auto-merging numbers
CONFLICT ( file/directory) : directory in the way of whatever from side1; moving it to whatever~side1 instead.
CONFLICT ( modify/delete) : whatever~side1 deleted in side2 and modified in side1. Version side1 of whatever~side1 left in tree.
EOF
test_cmp expect actual
'
for opt in $( git merge-tree --git-completion-helper-all)
do
if test $opt = "--trivial-merge" || test $opt = "--write-tree"
then
continue
fi
test_expect_success " usage: --trivial-merge is incompatible with $opt " '
test_expect_code 128 git merge-tree --trivial-merge $opt side1 side2 side3
'
done
2022-06-18 02:20:52 +02:00
test_expect_success 'Just the conflicted files without the messages' '
2022-06-18 02:20:53 +02:00
test_expect_code 1 git merge-tree --write-tree --no-messages --name-only side1 side2 >out &&
2022-06-18 02:20:52 +02:00
anonymize_hash out >actual &&
test_write_lines HASH greeting whatever~side1 >expect &&
test_cmp expect actual
'
2022-06-18 02:20:53 +02:00
test_expect_success 'Check conflicted oids and modes without messages' '
test_expect_code 1 git merge-tree --write-tree --no-messages side1 side2 >out &&
anonymize_hash out >actual &&
# Compare the basic output format
q_to_tab >expect <<-\E OF &&
HASH
100644 HASH 1Qgreeting
100644 HASH 2Qgreeting
100644 HASH 3Qgreeting
100644 HASH 1Qwhatever~side1
100644 HASH 2Qwhatever~side1
EOF
test_cmp expect actual &&
# Check the actual hashes against the `ls-files -u` output too
tail -n +2 out | sed -e s/side1/HEAD/ >actual &&
test_cmp conflicted-file-info actual
'
2022-06-18 02:20:58 +02:00
test_expect_success 'NUL terminated conflicted file "lines"' '
git checkout -b tweak1 side1 &&
test_write_lines zero 1 2 3 4 5 6 >numbers &&
git add numbers &&
git mv numbers "Αυτά μου φαίνονται κινέζικα" &&
git commit -m "Renamed numbers" &&
test_expect_code 1 git merge-tree --write-tree -z tweak1 side2 >out &&
anonymize_hash out >actual &&
printf "\\n" >>actual &&
# Expected results:
# "greeting" should merge with conflicts
# "whatever" has *both* a modify/delete and a file/directory conflict
# "Αυτά μου φαίνονται κινέζικα" should have a conflict
echo HASH | lf_to_nul >expect &&
q_to_tab <<-EOF | lf_to_nul >>expect &&
100644 HASH 1Qgreeting
100644 HASH 2Qgreeting
100644 HASH 3Qgreeting
100644 HASH 1Qwhatever~tweak1
100644 HASH 2Qwhatever~tweak1
100644 HASH 1QΑ υ τά μου φαίνονται κινέζικα
100644 HASH 2QΑ υ τά μου φαίνονται κινέζικα
100644 HASH 3QΑ υ τά μου φαίνονται κινέζικα
EOF
q_to_nul <<-EOF >>expect &&
1QgreetingQAuto-mergingQAuto-merging greeting
Q1QgreetingQCONFLICT ( contents) QCONFLICT ( content) : Merge conflict in greeting
Q2Qwhatever~tweak1QwhateverQCONFLICT ( file/directory) QCONFLICT ( file/directory) : directory in the way of whatever from tweak1; moving it to whatever~tweak1 instead.
Q1Qwhatever~tweak1QCONFLICT ( modify/delete) QCONFLICT ( modify/delete) : whatever~tweak1 deleted in side2 and modified in tweak1. Version tweak1 of whatever~tweak1 left in tree.
Q1QΑ υ τά μου φαίνονται κι ν έζι κα QAuto-mergingQAuto-merging Αυτά μου φαίνονται κινέζικα
Q1QΑ υ τά μου φαίνονται κι ν έζι κα QCONFLICT ( contents) QCONFLICT ( content) : Merge conflict in Αυτά μου φαίνονται κινέζικα
Q
EOF
test_cmp expect actual
'
merge-tree: implement real merges
This adds the ability to perform real merges rather than just trivial
merges (meaning handling three way content merges, recursive ancestor
consolidation, renames, proper directory/file conflict handling, and so
forth). However, unlike `git merge`, the working tree and index are
left alone and no branch is updated.
The only output is:
- the toplevel resulting tree printed on stdout
- exit status of 0 (clean), 1 (conflicts present), anything else
(merge could not be performed; unknown if clean or conflicted)
This output is meant to be used by some higher level script, perhaps in
a sequence of steps like this:
NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2)
test $? -eq 0 || die "There were conflicts..."
NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2)
git update-ref $BRANCH1 $NEWCOMMIT
Note that higher level scripts may also want to access the
conflict/warning messages normally output during a merge, or have quick
access to a list of files with conflicts. That is not available in this
preliminary implementation, but subsequent commits will add that
ability (meaning that NEWTREE would be a lot more than a tree in the
case of conflicts).
This also marks the traditional trivial merge of merge-tree as
deprecated. The trivial merge not only had limited applicability, the
output format was also difficult to work with (and its format
undocumented), and will generally be less performant than real merges.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-18 02:20:47 +02:00
test_done