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

From

Jeff King <peff@peff.net>

Date

Mar 24, 2011, 14:50 UTC

Message-ID

<20110324145047.GB16484@sigill.intra.peff.net>

In-Reply-To

<7vvcz9cyxd.fsf@alter.siamese.dyndns.org>

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

> > 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?

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