Re: [PATCH 3/3] show: turn on rename progress

On Wed, Mar 23, 2011 at 02:25:02PM -0700, Junio C Hamano wrote:

quoted

This makes sense for "show", which is showing a single diff,
since the progress reporting will be shown before the pager
shows any output.

We don't want to do the same for "log", though, because the
progress would be interspersed with the various commits.

I understand that you said q&d, but these days since f222abd (Make 'git
show' more useful, 2009-07-13), show does walk when it is asked to.

"git show master maint" will also be affected with this, no?

Ick, I didn't think of that. So yeah, that patch as-is is definitely no
good. I think the most sensible thing to do is to show progress only
until we actually generate some output. That handles both the walking
case and the "git show master maint" case.

Something like this:

diff --git a/builtin/log.c b/builtin/log.c
index 707fd57..d652acc 100644
--- a/builtin/log.c
+++ b/builtin/log.c

@@ -265,13 +265,16 @@ static int cmd_log_walk(struct rev_info *rev)
 	 * retain that state information if replacing rev->diffopt in this loop
 	 */
 	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)
 			/*
 			 * We decremented max_count in get_revision,
 			 * but we didn't actually show the commit.
 			 */
 			rev->max_count++;
+		if (showed && rev->diffopt.show_rename_progress)
+			rev->diffopt.show_rename_progress = 0;
 		if (!rev->reflog_info) {
 			/* we allow cycles in reflog ancestry */
 			free(commit->buffer);

@@ -416,6 +419,7 @@ int cmd_show(int argc, const char **argv, const char *prefix)
 	rev.diff = 1;
 	rev.always_show_header = 1;
 	rev.no_walk = 1;
+	rev.diffopt.show_rename_progress = 1;
 	memset(&opt, 0, sizeof(opt));
 	opt.def = "HEAD";
 	opt.tweak = show_rev_tweak_rev;

We could also turn it on for "git log" in that case, though it is only
useful if the first commit happens to be the one that is slow.

I should also turn it on for "git diff". I'll prepare a cleaner series
with that in it, too.

What about the degrade-cc-to-c warnings? Are you working on another
revision, or should I re-roll your changes on top of my series, handling
the "one-warning-per-commit" behavior I suggested when stdout and stderr
are combined?

-Peff