From: Jeff King <peff@peff.net>
Date: Wed, 06 Nov 2019 04:09:55 GMT
Subject: Re: [PATCH v2 1/1] commit-graph: use start_delayed_progress()
Message-ID: <20191106040955.GD4307@sigill.intra.peff.net>
In-Reply-To: <78bd6bc2c02f1daf13938a738d8eae56b5f6b74c.1572984842.git.gitgitgadget@gmail.com>

On Tue, Nov 05, 2019 at 08:14:02PM +0000, Derrick Stolee via GitGitGadget wrote:

> From: Derrick Stolee <dstolee@microsoft.com>
> 
> When writing a commit-graph, we show progress along several commit
> walks. When we use start_delayed_progress(), the progress line will
> only appear if that step takes a decent amount of time.
> 
> However, one place was missed: computing generation numbers. This is
> normally a very fast operation as all commits have been parsed in a
> previous step. But, this is showing up for all users no matter how few
> commits are being added.

Yep, makes sense (especially that it should all the other progress as
part of the same process).

> Now that we changed this method, very fast commands show no progess at
> all. This means we need to stop testing for seeing these progress lines
> in the test suite.

I think this is OK for now, though it does make me wonder if
"--progress" ought to perhaps override "delayed" in some instances,
since it's a positive signal from the caller that they're interested in
seeing progress.

-Peff