git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/3] show: turn on rename progress
Date: Fri, 25 Mar 2011 02:17:44 -0400	[thread overview]
Message-ID: <20110325061744.GA6261@sigill.intra.peff.net> (raw)
In-Reply-To: <7vzkok6qie.fsf@alter.siamese.dyndns.org> <7v4o6s86kr.fsf@alter.siamese.dyndns.org>

On Thu, Mar 24, 2011 at 04:03:16PM -0700, Junio C Hamano wrote:

> >   [1/4]: pager: save the original stderr when redirecting to pager
> >   [2/4]: progress: use pager's original_stderr if available
> >   [3/4]: show: turn on rename detection progress reporting
> >   [4/4]: diff: turn on rename detection progress reporting
> 
> Thanks, but why does it affect t0101 and many others...?

Because I'm an idiot who, despite manually testing the option-parsing
part of the code a million times, didn't actually run the full suite.

> >  	while ((commit = get_revision(rev)) != NULL) {
> > -		if (!log_tree_commit(rev, commit) &&
> > +		int showed = log_tree_commit(rev, commit);
> > +		if (showed &&
> >  		    rev->max_count >= 0)

Ugh. Of course, it should be:


diff --git a/builtin/log.c b/builtin/log.c
index 4d52e99..b19e10d 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -275,7 +275,7 @@ static int cmd_log_walk(struct rev_info *rev)
 	 */
 	while ((commit = get_revision(rev)) != NULL) {
 		int showed = log_tree_commit(rev, commit);
-		if (showed &&
+		if (!showed &&
 		    rev->max_count >= 0)
 			/*
 			 * We decremented max_count in get_revision,

on top.

> After looking at the implementation of log_tree_commit(), shouldn't this
> part be more like this?
> 
> 	int shown = log_tree_commit(rev, commit);
>         if (!shown && rev->max_count >=0)
>         	rev->max_count++;
> 	if (shown)
>         	rev->diffopt.show_rename_progress = 0;

Yes. You shouldn't even need to look at log_tree_commit; you can see in
the hunk of my patch that I accidentally inverted the unrelated
max_count conditional while factoring out the call.

I'll go find a brown paper bag now.

-Peff

PS I assume you can squash in the above, or take your version (I don't
care about the verb tense we use, but re-indenting the max_count
conditional as you did is good style).

      reply	other threads:[~2011-03-25  6:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-22 21:45 [PATCH] builtin/diff.c: remove duplicated call to diff_result_code() Junio C Hamano
2011-03-22 21:50 ` [PATCH 1/3] diffcore-rename: refactor "too many candidates" logic Junio C Hamano
2011-03-22 21:50   ` [PATCH 2/3] diffcore-rename: record filepair for rename src Junio C Hamano
2011-03-22 21:50   ` [PATCH 3/3] diffcore-rename: fall back to -C when -C -C busts the rename limit Junio C Hamano
2011-03-23 15:58     ` Jeff King
2011-03-23 16:41       ` Junio C Hamano
2011-03-23 16:50         ` Jeff King
2011-03-23 18:17       ` Jeff King
2011-03-23 18:18         ` [PATCH 1/3] pager: save the original stderr when redirecting to pager Jeff King
2011-03-23 18:19         ` [PATCH 2/3] progress: use pager's original_stderr if available Jeff King
2011-03-23 18:19         ` [PATCH 3/3] show: turn on rename progress Jeff King
2011-03-23 21:25           ` Junio C Hamano
2011-03-24 14:50             ` Jeff King
2011-03-24 15:00               ` Junio C Hamano
2011-03-24 17:45                 ` Jeff King
2011-03-24 17:46                   ` [PATCH 1/4] pager: save the original stderr when redirecting to pager Jeff King
2011-03-24 17:47                   ` [PATCH 2/4] progress: use pager's original_stderr if available Jeff King
2011-03-24 17:49                   ` [PATCH 3/4] show: turn on rename detection progress reporting Jeff King
2011-03-24 23:35                     ` Junio C Hamano
2011-03-24 17:51                   ` [PATCH 4/4] diff: " Jeff King
2011-03-25  8:35                     ` Johannes Sixt
2011-03-25  9:09                       ` Jeff King
2011-03-24 23:03                   ` [PATCH 3/3] show: turn on rename progress Junio C Hamano
2011-03-25  6:17                     ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110325061744.GA6261@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).