aboutsummaryrefslogtreecommitdiff
path: root/t/t7007-show.sh
Commit message (Collapse)AuthorAge
* revision: forbid combining --graph and --no-walkDongcan Jiang2015-03-19
| | | | | | | | | | | | | | | | | | | | | | | | Because "--graph" is about connected history while --no-walk is about discrete points, it does not make sense to allow these two options at the same time. [1] This change makes a few calls to "show --graph" fail in t4052, but asking to show one commit with graph is a nonsensical thing to do. Thus, tests on "show --graph" in t4052 have been removed [2,3]. Same tests on "show" without --graph option have already been tested in 4052. 3 testcases have been added to test this patch. [1]: http://article.gmane.org/gmane.comp.version-control.git/216083 [2]: http://article.gmane.org/gmane.comp.version-control.git/264950 [3]: http://article.gmane.org/gmane.comp.version-control.git/265107 Helped-By: Eric Sunshine <sunshine@sunshineco.com> Helped-By: René Scharfe <l.s.r@web.de> Helped-By: Junio C Hamano <gitster@pobox.com> Signed-off-by: Dongcan Jiang <dongcan.jiang@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-show: fix 'git show -s' to not add extra terminator after merge commitMax Kirillov2014-05-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When git show -s is called for merge commit it prints extra newline after any merge commit. This differs from output for commits with one parent. Fix it by more thorough checking that diff output is disabled. The code in question exists since commit 3969cf7db1. The additional newline is really needed for cases when patch is requested, test t4013-diff-various.sh contains cases which can demonstrate behavior when the condition is restricted further. Tests: Added merge commit to 'set up a bit of history' case in t7007-show.sh to cover the fix. Existing tests are updated to demonstrate the new behaviour. Earlier, the tests that used "git show -s --pretty=format:%s", even though "--pretty=format:%s" calls for item separator semantics and does not ask for the terminating newline after the last item, expected the output to end with such a newline. They were relying on the buggy behaviour. Use of "--format=%s", which is equivalent to "--pretty=tformat:%s" that asks for a terminating newline after each item, is a more realistic way to use the command. In the test 'merge log messages' the expected data is changed, because it was explicitly listing the extra newline. Also the msg.nologff and msg.nolognoff expected files are replaced by one msg.nolog, because they were diffing because of the bug, and now there should be no difference. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* log: fix --quiet synonym for -sJeff King2012-08-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* show: fix "range implies walking"Junio C Hamano2012-06-19
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Demonstrate git-show is broken with rangesThomas Rast2012-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* git-show: do not segfault when showing a bad tagJunio C Hamano2008-12-15
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>