2008-12-15 08:36:56 +00:00
|
|
|
#!/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 20:04:57 +00: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 &&
|
2014-05-14 22:12:45 +00:00
|
|
|
test_commit side3 &&
|
|
|
|
test_merge merge main3
|
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 20:04:57 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2012-06-19 21:15:57 +00:00
|
|
|
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 20:04:57 +00: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
|
|
|
|
'
|
|
|
|
|
2012-06-19 21:15:57 +00:00
|
|
|
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 20:04:57 +00: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
|
|
|
|
'
|
|
|
|
|
log: fix --quiet synonym for -s
Originally the "--quiet" option was parsed by the
diff-option parser into the internal QUICK option. This had
the effect of silencing diff output from the log (which was
not intended, but happened to work and people started to
use it). But it also had other odd side effects at the diff
level (for example, it would suppress the second commit in
"git show A B").
To fix this, commit 1c40c36 converted log to parse-options
and handled the "quiet" option separately, not passing it
on to the diff code. However, it simply ignored the option,
which was a regression for people using it as a synonym for
"-s". Commit 01771a8 then fixed that by interpreting the
option to add DIFF_FORMAT_NO_OUTPUT to the list of output
formats.
However, that commit did not fix it in all cases. It sets
the flag after setup_revisions is called. Naively, this
makes sense because you would expect the setup_revisions
parser to overwrite our output format flag if "-p" or
another output format flag is seen.
However, that is not how the NO_OUTPUT flag works. We
actually store it in the bit-field as just another format.
At the end of setup_revisions, we call diff_setup_done,
which post-processes the bitfield and clears any other
formats if we have set NO_OUTPUT. By setting the flag after
setup_revisions is done, diff_setup_done does not have a
chance to make this tweak, and we end up with other format
options still set.
As a result, the flag would have no effect in "git log -p
--quiet" or "git show --quiet". Fix it by setting the
format flag before the call to setup_revisions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-28 21:29:34 +00:00
|
|
|
test_expect_success '-s suppresses diff' '
|
2014-05-14 22:12:45 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
merge
|
|
|
|
main3
|
|
|
|
EOF
|
|
|
|
git show -s --format=%s merge main3 >actual &&
|
log: fix --quiet synonym for -s
Originally the "--quiet" option was parsed by the
diff-option parser into the internal QUICK option. This had
the effect of silencing diff output from the log (which was
not intended, but happened to work and people started to
use it). But it also had other odd side effects at the diff
level (for example, it would suppress the second commit in
"git show A B").
To fix this, commit 1c40c36 converted log to parse-options
and handled the "quiet" option separately, not passing it
on to the diff code. However, it simply ignored the option,
which was a regression for people using it as a synonym for
"-s". Commit 01771a8 then fixed that by interpreting the
option to add DIFF_FORMAT_NO_OUTPUT to the list of output
formats.
However, that commit did not fix it in all cases. It sets
the flag after setup_revisions is called. Naively, this
makes sense because you would expect the setup_revisions
parser to overwrite our output format flag if "-p" or
another output format flag is seen.
However, that is not how the NO_OUTPUT flag works. We
actually store it in the bit-field as just another format.
At the end of setup_revisions, we call diff_setup_done,
which post-processes the bitfield and clears any other
formats if we have set NO_OUTPUT. By setting the flag after
setup_revisions is done, diff_setup_done does not have a
chance to make this tweak, and we end up with other format
options still set.
As a result, the flag would have no effect in "git log -p
--quiet" or "git show --quiet". Fix it by setting the
format flag before the call to setup_revisions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-28 21:29:34 +00:00
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--quiet suppresses diff' '
|
|
|
|
echo main3 >expect &&
|
|
|
|
git show --quiet --format=%s main3 >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2008-12-15 08:36:56 +00:00
|
|
|
test_done
|