microsoft
/
git
зеркало из https://github.com/microsoft/git.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
git/t/t6060-merge-index.sh

101 строка
2.2 KiB
Bash
Исходник Обычный вид История

add tests for merge-index / merge-one-file There were no tests for either, except a brief use in t1200-tutorial. These tools are not used much these days, as most people use the merge-recursive strategy, which handles everything internally. However, they are used by the "octopus" and "resolve" strategies, as well as any custom strategies or merge scripts people have built around them. For example, together with read-tree, they are the simplest way to do a basic content-level merge without checking out the entire repository contents beforehand. This script adds a basic test of the tools to perform one content-level merge. It also shows a failure of the tools to work properly in the face of GIT_WORK_TREE or core.worktree. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-30 02:23:54 +04:00
#!/bin/sh
test_description='basic git merge-index / git-merge-one-file tests'
. ./test-lib.sh
test_expect_success 'setup diverging branches' '
for i in 1 2 3 4 5 6 7 8 9 10; do
echo $i
done >file &&
git add file &&
git commit -m base &&
git tag base &&
sed s/2/two/ <file >tmp &&
mv tmp file &&
git commit -a -m two &&
git tag two &&
git checkout -b other HEAD^ &&
sed s/10/ten/ <file >tmp &&
mv tmp file &&
git commit -a -m ten &&
git tag ten
'
cat >expect-merged <<'EOF'
1
two
3
4
5
6
7
8
9
ten
EOF
test_expect_success 'read-tree does not resolve content merge' '
git read-tree -i -m base ten two &&
echo file >expect &&
git diff-files --name-only --diff-filter=U >unmerged &&
test_cmp expect unmerged
'
test_expect_success 'git merge-index git-merge-one-file resolves' '
git merge-index git-merge-one-file -a &&
git diff-files --name-only --diff-filter=U >unmerged &&
>expect &&
test_cmp expect unmerged &&
test_cmp expect-merged file &&
git cat-file blob :file >file-index &&
test_cmp expect-merged file-index
'
test_expect_success 'setup bare merge' '
git clone --bare . bare.git &&
(cd bare.git &&
GIT_INDEX_FILE=$PWD/merge.index &&
export GIT_INDEX_FILE &&
git read-tree -i -m base ten two
)
'
test_expect_success 'merge-one-file fails without a work tree' '
(cd bare.git &&
GIT_INDEX_FILE=$PWD/merge.index &&
export GIT_INDEX_FILE &&
test_must_fail git merge-index git-merge-one-file -a
)
'
merge-one-file: fix broken merges with alternate work trees The merge-one-file tool predates the invention of GIT_WORK_TREE. By the time GIT_WORK_TREE was invented, most people were using the merge-recursive strategy, which handles resolving internally. Therefore these features have had very little testing together. For the most part, merge-one-file just works with GIT_WORK_TREE; most of its heavy lifting is done by plumbing commands which do respect GIT_WORK_TREE properly. The one exception is a shell redirection which touches the worktree directly, writing results to the wrong place in the presence of a GIT_WORK_TREE variable. This means that merges won't even fail; they will silently produce incorrect results, throwing out the entire "theirs" side of files which need content-level merging! This patch makes merge-one-file chdir to the toplevel of the working tree (and exit if we don't have one). This most closely matches the assumption made by the original script (before separate work trees were invented), and matches what happens when the script is called as part of a merge strategy. While we're at it, we'll also error-check the call to cat. Merging a file in a subdirectory could in fact fail, as the redirection relies on the "checkout-index" call just prior to create leading directories. But we never noticed, since we ignored the error return from running cat. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-30 02:24:32 +04:00
test_expect_success 'merge-one-file respects GIT_WORK_TREE' '
add tests for merge-index / merge-one-file There were no tests for either, except a brief use in t1200-tutorial. These tools are not used much these days, as most people use the merge-recursive strategy, which handles everything internally. However, they are used by the "octopus" and "resolve" strategies, as well as any custom strategies or merge scripts people have built around them. For example, together with read-tree, they are the simplest way to do a basic content-level merge without checking out the entire repository contents beforehand. This script adds a basic test of the tools to perform one content-level merge. It also shows a failure of the tools to work properly in the face of GIT_WORK_TREE or core.worktree. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-30 02:23:54 +04:00
(cd bare.git &&
mkdir work &&
GIT_WORK_TREE=$PWD/work &&
export GIT_WORK_TREE &&
GIT_INDEX_FILE=$PWD/merge.index &&
export GIT_INDEX_FILE &&
git merge-index git-merge-one-file -a &&
git cat-file blob :file >work/file-index
) &&
test_cmp expect-merged bare.git/work/file &&
test_cmp expect-merged bare.git/work/file-index
'
merge-one-file: fix broken merges with alternate work trees The merge-one-file tool predates the invention of GIT_WORK_TREE. By the time GIT_WORK_TREE was invented, most people were using the merge-recursive strategy, which handles resolving internally. Therefore these features have had very little testing together. For the most part, merge-one-file just works with GIT_WORK_TREE; most of its heavy lifting is done by plumbing commands which do respect GIT_WORK_TREE properly. The one exception is a shell redirection which touches the worktree directly, writing results to the wrong place in the presence of a GIT_WORK_TREE variable. This means that merges won't even fail; they will silently produce incorrect results, throwing out the entire "theirs" side of files which need content-level merging! This patch makes merge-one-file chdir to the toplevel of the working tree (and exit if we don't have one). This most closely matches the assumption made by the original script (before separate work trees were invented), and matches what happens when the script is called as part of a merge strategy. While we're at it, we'll also error-check the call to cat. Merging a file in a subdirectory could in fact fail, as the redirection relies on the "checkout-index" call just prior to create leading directories. But we never noticed, since we ignored the error return from running cat. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-30 02:24:32 +04:00
test_expect_success 'merge-one-file respects core.worktree' '
add tests for merge-index / merge-one-file There were no tests for either, except a brief use in t1200-tutorial. These tools are not used much these days, as most people use the merge-recursive strategy, which handles everything internally. However, they are used by the "octopus" and "resolve" strategies, as well as any custom strategies or merge scripts people have built around them. For example, together with read-tree, they are the simplest way to do a basic content-level merge without checking out the entire repository contents beforehand. This script adds a basic test of the tools to perform one content-level merge. It also shows a failure of the tools to work properly in the face of GIT_WORK_TREE or core.worktree. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-30 02:23:54 +04:00
mkdir subdir &&
git clone . subdir/child &&
(cd subdir &&
GIT_DIR=$PWD/child/.git &&
export GIT_DIR &&
git config core.worktree "$PWD/child" &&
git read-tree -i -m base ten two &&
git merge-index git-merge-one-file -a &&
git cat-file blob :file >file-index
) &&
test_cmp expect-merged subdir/child/file &&
test_cmp expect-merged subdir/file-index
'
test_done