summaryrefslogtreecommitdiff
path: root/t/t7007-show.sh
AgeCommit message (Collapse)AuthorFilesLines
2012-08-28log: fix --quiet synonym for -sLibravatar Jeff King1-0/+12
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-06-19show: fix "range implies walking"Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-19Demonstrate git-show is broken with rangesLibravatar Thomas Rast1-0/+91
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>
2008-12-15git-show: do not segfault when showing a bad tagLibravatar Junio C Hamano1-0/+20
When a tag points at a bad or nonexistent object, we should diagnose the breakage and exit. An earlier commit 4f3dcc2 (Fix 'git show' on signed tag of signed tag of commit, 2008-07-01) lost this check and made it segfault instead; not good. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>