On 11/5/2019 11:09 PM, Jeff King wrote: > On Tue, Nov 05, 2019 at 08:14:02PM +0000, Derrick Stolee via GitGitGadget wrote: > >> From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >> >> 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. I was thinking that we could start with a GIT_TEST_PROGRESS environment variable to force all delayed progress to act like non-delayed progress. That would at least give us confirmation on these kinds of tests. The impact of doing that inside the progress code could be large, so perhaps that is best left for a follow-up. Thanks, -Stolee
