Re: [PATCH 7/9] fetch: fetch submodules in parallel

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 28, 2015, 18:42 UTC
Message-ID: <20150828184250.GD8165@google.com>
In-Reply-To: <xmqqpp271d6v.fsf@gitster.mtv.corp.google.com>

Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:

Show 8 quoted lines

>>  remote: Finding sources:  11% (18/155)           \r
>>  remote: Finding sources:  12% (19/155)           \r
>>
>> With multiple commands producing such output, they will overwrite each
>> other's lines, producing a mixture that is confusing and unuseful.
>
> That example also illustrates why it is not a useful to buffer all
> of these lines and showing them once.

I don't completely follow. Are you referring to the wasted memory to store the line that is going to be written and rewritten or some other aspect?

Today (without parallelism), if I clone a repository with multiple submodules and walk away from the terminal, then when I get back I see

	Cloning into 'plugins/cookbook-plugin'...
	remote: Counting objects: 36, done
	remote: Finding sources: 100% (36/36)
	remote: Total 1192 (delta 196), reused 1192 (delta 196)
	Receiving objects: 100% (1192/1192), 239.46 KiB | 0 bytes/s, done.
	Resolving deltas: 100% (196/196), done.
	Checking connectivity... done.
	Submodule path 'plugins/cookbook-plugin': checked out 'b9d3ca8a65030071e28be19296ba867ab424fbbf'
	Cloning into 'plugins/download-commands'...
	remote: Counting objects: 37, done
	remote: Finding sources: 100% (37/37)
	remote: Total 448 (delta 46), reused 448 (delta 46)
	Receiving objects: 100% (448/448), 96.13 KiB | 0 bytes/s, done.
	Resolving deltas: 100% (46/46), done.
	Checking connectivity... done.
	Submodule path 'plugins/download-commands': checked out '99e61fb06a4505a9558c23a56213cb32ceaa9cca'
	...

The output for each submodule is in one chunk and I can understand what happened in each.

By contrast, with inter-mixing the speed of output tells you something about whether the process is stalled while you stare at the screen and wait for it to finish (good) but the result on the screen is unintelligible when the process finishes (bad).

Showing interactive output for one task still provides the real-time feedback about whether it is completely stuck and needs to be cancelled. It is easier to make sense of even from the point of view of real-time progress than the intermixed output.

What problem is the intermixed output meant to solve?

In other words, what is your objection about? Perhaps there is a way to both satisfy that objection and to have output clumped per task, but it is hard to know without knowing what the objection is.

Hope that helps, Jonathan