Elijah Newren <newren@xxxxxxxxx> writes:
> Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
> ---
> t/t6036-recursive-corner-cases.sh | 149 +++++++++++++++++++++++++++++++++++++
> 1 files changed, 149 insertions(+), 0 deletions(-)
>
> diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
> index dab52a4..4993f67 100755
> --- a/t/t6036-recursive-corner-cases.sh
> +++ b/t/t6036-recursive-corner-cases.sh
> @@ -397,4 +397,153 @@ test_expect_failure 'git detects conflict w/ criss-cross+contrived resolution' '
> test $(git rev-parse :3:file) = $(git rev-parse E:file)
> '
>
> +#
> +# criss-cross + d/f conflict via add/add:
> +# Commit A: Neither file 'a' nor directory 'a/' exist.
> +# Commit B: Introduce 'a'
> +# Commit C: Introduce 'a/file'
> +# Two different later cases:
> +# Commit D1: Merge B & C, keeping 'a' and deleting 'a/'
> +# Commit E1: Merge B & C, deleting 'a' but keeping 'a/file'
Where does the content of a/file (or a) go? Discarded?
> +# Commit D2: Merge B & C, keeping a modified 'a' and deleting 'a/'
> +# Commit E2: Merge B & C, deleting 'a' but keeping a modified 'a/file'
What "modification" is there to be made? Are these evil merges?
> +# Note: D == D1.
If you are not building nor testing D2, do not bring it up in the above
description. Otherwise, use D1 and D2 throughout the test and description.
> +# Finally, someone goes to merge D1&E1 or D1&E2 or D2&E1. What happens?
State what _should_ happen here. We are not wasting brainwave for mental
masturbation but are trying to solve real problems for real projects here.
Also aren't we interested in what should happen when D2 and E2 are merged?
If not why not?
> +# B D1 or D2
> +# o---o (file)
> +# / \ / \
> +# A o X ? F
> +# \ / \ /
> +# o---o
> +# C E1 or E2 (dir)
> +#
> +test_expect_failure 'git detects conflict and handles merge of D & E1 correctly' '
> + git reset --hard &&
> + git reset --hard &&
> + git clean -fdqx &&
> + git checkout D^0 &&
Why do you need to reset twice? Superstition (you have a commented one
introduced later in the series --- perhaps this shows a bug in reset)?
"Start with a clean state at this commit (in this case D^0)" needs a
helper shell function to make everything below easier to read.
> + # FIXME: If merge-base could keep both a and a/file in its tree, then
> + # we could this merge would actually be able to succeed.
What exactly do you refer to in the above sentence with "merge-base"?
> + test_must_fail git merge -s recursive E1^0 &&
> +
> + test 2 -eq $(git ls-files -s | wc -l) &&
> + test 1 -eq $(git ls-files -u | wc -l) &&
> + test 0 -eq $(git ls-files -o | wc -l) &&
> +
> + test $(git rev-parse :2:a) = $(git rev-parse B:a)
> +'
What is expected here? "a" at stage #2 ("a" from B) is being tested, and
what is the other entry? "a/file" at stage #3 ("a/file" from E1) or
something else? What should the working tree have?
> +test_expect_failure 'git detects conflict and handles merge of E1 & D correctly' '
Instead of saying "correctly", state what you think should happen, in
other words, what your definition of "correct" is, because in these
made-up cases what is expected could be vastly different from people to
people.
This is the same merge in the opposite direction, right?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html