1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-18 15:04:49 +01:00
git/t/t7007-show.sh

112 lines
2.7 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='git show'
. ./test-lib.sh
test_expect_success setup '
echo hello world >foo &&
H=$(git hash-object -w foo) &&
git tag -a foo-tag -m "Tags $H" $H &&
HH=$(expr "$H" : "\(..\)") &&
H38=$(expr "$H" : "..\(.*\)") &&
rm -f .git/objects/$HH/$H38
'
test_expect_success 'showing a tag that point at a missing object' '
test_must_fail git --no-pager show foo-tag
'
Demonstrate git-show is broken with ranges The logic of git-show has remained largely unchanged since around 5d7eeee (git-show: grok blobs, trees and tags, too, 2006-12-14): start a revision walker with no_walk=1, look at its pending objects and handle them one-by-one. For commits, this means stuffing them into a new queue all alone, and running the walker. Then Linus's f222abd (Make 'git show' more useful, 2009-07-13) came along and set no_walk=0 whenever the user specifies a range. Which appears to work fine, until you actually prod it hard enough, as the preceding commit shows: UNINTERESTING commits will be marked as such, but not walked further to propagate the marks. Demonstrate this with the main tests of this patch: 'showing a range walks (Y shape)'. The Y shape of history ensures that propagating the UNINTERESTING marks is necessary to correctly exclude the main1 commit. The only example I could find actually requires that the negative revisions are listed later, and in this scenario a dotted range actually works. However, it is easy to find examples in git.git where a dotted range is wrong, e.g. $ git show v1.7.0..v1.7.1 | grep ^commit | wc -l 1297 $ git rev-list v1.7.0..v1.7.1 | wc -l 702 While there, also test a few other things that are not covered so far: the -N way of triggering a range (added in 5853cae, DWIM 'git show -5' to 'git show --do-walk -5', 2010-06-01), and the interactions of tags, commits and ranges. Pointed out by Dr_Memory on #git. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-19 22:04:57 +02:00
test_expect_success 'set up a bit of history' '
test_commit main1 &&
test_commit main2 &&
test_commit main3 &&
git tag -m "annotated tag" annotated &&
git checkout -b side HEAD^^ &&
test_commit side2 &&
test_commit side3
'
test_expect_success 'showing two commits' '
cat >expect <<-EOF &&
commit $(git rev-parse main2)
commit $(git rev-parse main3)
EOF
git show main2 main3 >actual &&
grep ^commit actual >actual.filtered &&
test_cmp expect actual.filtered
'
test_expect_success 'showing a range walks (linear)' '
cat >expect <<-EOF &&
commit $(git rev-parse main3)
commit $(git rev-parse main2)
EOF
git show main1..main3 >actual &&
grep ^commit actual >actual.filtered &&
test_cmp expect actual.filtered
'
test_expect_success 'showing a range walks (Y shape, ^ first)' '
cat >expect <<-EOF &&
commit $(git rev-parse main3)
commit $(git rev-parse main2)
EOF
git show ^side3 main3 >actual &&
grep ^commit actual >actual.filtered &&
test_cmp expect actual.filtered
'
test_expect_success 'showing a range walks (Y shape, ^ last)' '
Demonstrate git-show is broken with ranges The logic of git-show has remained largely unchanged since around 5d7eeee (git-show: grok blobs, trees and tags, too, 2006-12-14): start a revision walker with no_walk=1, look at its pending objects and handle them one-by-one. For commits, this means stuffing them into a new queue all alone, and running the walker. Then Linus's f222abd (Make 'git show' more useful, 2009-07-13) came along and set no_walk=0 whenever the user specifies a range. Which appears to work fine, until you actually prod it hard enough, as the preceding commit shows: UNINTERESTING commits will be marked as such, but not walked further to propagate the marks. Demonstrate this with the main tests of this patch: 'showing a range walks (Y shape)'. The Y shape of history ensures that propagating the UNINTERESTING marks is necessary to correctly exclude the main1 commit. The only example I could find actually requires that the negative revisions are listed later, and in this scenario a dotted range actually works. However, it is easy to find examples in git.git where a dotted range is wrong, e.g. $ git show v1.7.0..v1.7.1 | grep ^commit | wc -l 1297 $ git rev-list v1.7.0..v1.7.1 | wc -l 702 While there, also test a few other things that are not covered so far: the -N way of triggering a range (added in 5853cae, DWIM 'git show -5' to 'git show --do-walk -5', 2010-06-01), and the interactions of tags, commits and ranges. Pointed out by Dr_Memory on #git. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-19 22:04:57 +02:00
cat >expect <<-EOF &&
commit $(git rev-parse main3)
commit $(git rev-parse main2)
EOF
git show main3 ^side3 >actual &&
grep ^commit actual >actual.filtered &&
test_cmp expect actual.filtered
'
test_expect_success 'showing with -N walks' '
cat >expect <<-EOF &&
commit $(git rev-parse main3)
commit $(git rev-parse main2)
EOF
git show -2 main3 >actual &&
grep ^commit actual >actual.filtered &&
test_cmp expect actual.filtered
'
test_expect_success 'showing annotated tag' '
cat >expect <<-EOF &&
tag annotated
commit $(git rev-parse annotated^{commit})
EOF
git show annotated >actual &&
grep -E "^(commit|tag)" actual >actual.filtered &&
test_cmp expect actual.filtered
'
test_expect_success 'showing annotated tag plus commit' '
cat >expect <<-EOF &&
tag annotated
commit $(git rev-parse annotated^{commit})
commit $(git rev-parse side3)
EOF
git show annotated side3 >actual &&
grep -E "^(commit|tag)" actual >actual.filtered &&
test_cmp expect actual.filtered
'
test_expect_success 'showing range' '
Demonstrate git-show is broken with ranges The logic of git-show has remained largely unchanged since around 5d7eeee (git-show: grok blobs, trees and tags, too, 2006-12-14): start a revision walker with no_walk=1, look at its pending objects and handle them one-by-one. For commits, this means stuffing them into a new queue all alone, and running the walker. Then Linus's f222abd (Make 'git show' more useful, 2009-07-13) came along and set no_walk=0 whenever the user specifies a range. Which appears to work fine, until you actually prod it hard enough, as the preceding commit shows: UNINTERESTING commits will be marked as such, but not walked further to propagate the marks. Demonstrate this with the main tests of this patch: 'showing a range walks (Y shape)'. The Y shape of history ensures that propagating the UNINTERESTING marks is necessary to correctly exclude the main1 commit. The only example I could find actually requires that the negative revisions are listed later, and in this scenario a dotted range actually works. However, it is easy to find examples in git.git where a dotted range is wrong, e.g. $ git show v1.7.0..v1.7.1 | grep ^commit | wc -l 1297 $ git rev-list v1.7.0..v1.7.1 | wc -l 702 While there, also test a few other things that are not covered so far: the -N way of triggering a range (added in 5853cae, DWIM 'git show -5' to 'git show --do-walk -5', 2010-06-01), and the interactions of tags, commits and ranges. Pointed out by Dr_Memory on #git. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-19 22:04:57 +02:00
cat >expect <<-EOF &&
commit $(git rev-parse main3)
commit $(git rev-parse main2)
EOF
git show ^side3 annotated >actual &&
grep -E "^(commit|tag)" actual >actual.filtered &&
test_cmp expect actual.filtered
'
test_done