kernel/git - git - PowerEL Git System

Tree: 22ed792753

Author	SHA1	Message	Date
Jeff King	f9c75d858d	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>	13 years ago
Junio C Hamano	c5941f1aac	show: fix "range implies walking" Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	b0082b9d59	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>	13 years ago
Junio C Hamano	d2dadfe890	git-show: do not segfault when showing a bad tag 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>	16 years ago