git/t/t7060-wtstatus.sh

255 lines
6.1 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='basic work tree status reporting'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
test_expect_success setup '
git config --global advice.statusuoption false &&
test_commit A &&
test_commit B oneside added &&
git checkout A^0 &&
test_commit C oneside created
'
test_expect_success 'A/A conflict' '
git checkout B^0 &&
test_must_fail git merge C
'
test_expect_success 'Report path with conflict' '
git diff --cached --name-status >actual &&
echo "U oneside" >expect &&
test_cmp expect actual
'
test_expect_success 'Report new path with conflict' '
git diff --cached --name-status HEAD^ >actual &&
echo "U oneside" >expect &&
test_cmp expect actual
'
test_expect_success 'M/D conflict does not segfault' '
cat >expect <<EOF &&
On branch side
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add/rm <file>..." as appropriate to mark resolution)
deleted by us: foo
no changes added to commit (use "git add" and/or "git commit -a")
EOF
mkdir mdconflict &&
(
cd mdconflict &&
git init &&
test_commit initial foo "" &&
test_commit modify foo foo &&
git checkout -b side HEAD^ &&
git rm foo &&
git commit -m delete &&
test_must_fail git merge main &&
test_must_fail git commit --dry-run >../actual &&
test_cmp ../expect ../actual &&
git status >../actual &&
test_cmp ../expect ../actual
)
'
diffcore-rename: don't consider unmerged path as source Since e9c8409 (diff-index --cached --raw: show tree entry on the LHS for unmerged entries., 2007-01-05), an unmerged entry should be detected by using DIFF_PAIR_UNMERGED(p), not by noticing both one and two sides of the filepair records mode=0 entries. However, it forgot to update some parts of the rename detection logic. This only makes difference in the "diff --cached" codepath where an unmerged filepair carries information on the entries that came from the tree. It probably hasn't been noticed for a long time because nobody would run "diff -M" during a conflict resolution, but "git status" uses rename detection when it internally runs "diff-index" and "diff-files" and gives nonsense results. In an unmerged pair, "one" side can have a valid filespec to record the tree entry (e.g. what's in HEAD) when running "diff --cached". This can be used as a rename source to other paths in the index that are not unmerged. The path that is unmerged by definition does not have the final content yet (i.e. "two" side cannot have a valid filespec), so it can never be a rename destination. Use the DIFF_PAIR_UNMERGED() to detect unmerged filepair correctly, and allow the valid "one" side of an unmerged filepair to be considered a potential rename source, but never to be considered a rename destination. Commit message and first two test cases by Junio, the rest by Martin. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-24 02:41:01 +00:00
test_expect_success 'rename & unmerged setup' '
git rm -f -r . &&
cat "$TEST_DIRECTORY/README" >ONE &&
git add ONE &&
test_tick &&
git commit -m "One commit with ONE" &&
echo Modified >TWO &&
cat ONE >>TWO &&
cat ONE >>THREE &&
git add TWO THREE &&
sha1=$(git rev-parse :ONE) &&
git rm --cached ONE &&
(
echo "100644 $sha1 1 ONE" &&
echo "100644 $sha1 2 ONE" &&
echo "100644 $sha1 3 ONE"
) | git update-index --index-info &&
echo Further >>THREE
'
test_expect_success 'rename & unmerged status' '
git status -suno >actual &&
cat >expect <<-EOF &&
UU ONE
AM THREE
A TWO
EOF
test_cmp expect actual
'
test_expect_success 'git diff-index --cached shows 2 added + 1 unmerged' '
cat >expected <<-EOF &&
U ONE
A THREE
A TWO
EOF
git diff-index --cached --name-status HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'git diff-index --cached -M shows 2 added + 1 unmerged' '
cat >expected <<-EOF &&
U ONE
A THREE
A TWO
EOF
git diff-index --cached -M --name-status HEAD >actual &&
diffcore-rename: don't consider unmerged path as source Since e9c8409 (diff-index --cached --raw: show tree entry on the LHS for unmerged entries., 2007-01-05), an unmerged entry should be detected by using DIFF_PAIR_UNMERGED(p), not by noticing both one and two sides of the filepair records mode=0 entries. However, it forgot to update some parts of the rename detection logic. This only makes difference in the "diff --cached" codepath where an unmerged filepair carries information on the entries that came from the tree. It probably hasn't been noticed for a long time because nobody would run "diff -M" during a conflict resolution, but "git status" uses rename detection when it internally runs "diff-index" and "diff-files" and gives nonsense results. In an unmerged pair, "one" side can have a valid filespec to record the tree entry (e.g. what's in HEAD) when running "diff --cached". This can be used as a rename source to other paths in the index that are not unmerged. The path that is unmerged by definition does not have the final content yet (i.e. "two" side cannot have a valid filespec), so it can never be a rename destination. Use the DIFF_PAIR_UNMERGED() to detect unmerged filepair correctly, and allow the valid "one" side of an unmerged filepair to be considered a potential rename source, but never to be considered a rename destination. Commit message and first two test cases by Junio, the rest by Martin. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-24 02:41:01 +00:00
test_cmp expected actual
'
test_expect_success 'git diff-index --cached -C shows 2 copies + 1 unmerged' '
cat >expected <<-EOF &&
U ONE
C ONE THREE
C ONE TWO
EOF
git diff-index --cached -C --name-status HEAD |
sed "s/^C[0-9]*/C/g" >actual &&
test_cmp expected actual
'
test_expect_success 'status when conflicts with add and rm advice (deleted by them)' '
git reset --hard &&
git checkout main &&
test_commit init main.txt init &&
git checkout -b second_branch &&
git rm main.txt &&
git commit -m "main.txt deleted on second_branch" &&
test_commit second conflict.txt second &&
git checkout main &&
test_commit on_second main.txt on_second &&
test_commit main conflict.txt main &&
test_must_fail git merge second_branch &&
cat >expected <<\EOF &&
On branch main
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add/rm <file>..." as appropriate to mark resolution)
both added: conflict.txt
deleted by them: main.txt
no changes added to commit (use "git add" and/or "git commit -a")
EOF
git status --untracked-files=no >actual &&
test_cmp expected actual
'
test_expect_success 'prepare for conflicts' '
git reset --hard &&
git checkout -b conflict &&
test_commit one main.txt one &&
git branch conflict_second &&
git mv main.txt sub_main.txt &&
git commit -m "main.txt renamed in sub_main.txt" &&
git checkout conflict_second &&
git mv main.txt sub_second.txt &&
git commit -m "main.txt renamed in sub_second.txt"
'
test_expect_success 'status when conflicts with add and rm advice (both deleted)' '
test_must_fail git merge conflict &&
cat >expected <<\EOF &&
On branch conflict_second
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add/rm <file>..." as appropriate to mark resolution)
both deleted: main.txt
added by them: sub_main.txt
added by us: sub_second.txt
no changes added to commit (use "git add" and/or "git commit -a")
EOF
git status --untracked-files=no >actual &&
test_cmp expected actual
'
test_expect_success 'status when conflicts with only rm advice (both deleted)' '
git reset --hard conflict_second &&
test_must_fail git merge conflict &&
git add sub_main.txt &&
git add sub_second.txt &&
cat >expected <<\EOF &&
On branch conflict_second
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Changes to be committed:
new file: sub_main.txt
Unmerged paths:
(use "git rm <file>..." to mark resolution)
both deleted: main.txt
Untracked files not listed (use -u option to show untracked files)
EOF
git status --untracked-files=no >actual &&
test_cmp expected actual &&
git reset --hard &&
git checkout main
'
test_expect_success 'status --branch with detached HEAD' '
git reset --hard &&
git checkout main^0 &&
git status --branch --porcelain >actual &&
cat >expected <<-EOF &&
## HEAD (no branch)
?? .gitconfig
?? actual
?? expect
?? expected
?? mdconflict/
EOF
test_cmp expected actual
'
## Duplicate the above test and verify --porcelain=v1 arg parsing.
test_expect_success 'status --porcelain=v1 --branch with detached HEAD' '
git reset --hard &&
git checkout main^0 &&
git status --branch --porcelain=v1 >actual &&
cat >expected <<-EOF &&
## HEAD (no branch)
?? .gitconfig
?? actual
?? expect
?? expected
?? mdconflict/
EOF
test_cmp expected actual
'
## Verify parser error on invalid --porcelain argument.
test_expect_success 'status --porcelain=bogus' '
test_must_fail git status --porcelain=bogus
'
test_done