Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 04 Oct 2017, at 12:52, Lars Schneider <larsxschneider@xxxxxxxxx> wrote:
> 
> 
>> On 24 Aug 2017, at 21:40, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> 
>> Lars Schneider <larsxschneider@xxxxxxxxx> writes:
>> 
>>> In 2841e8f ("convert: add "status=delayed" to filter process protocol",
>>> 2017-06-30) we taught the filter process protocol to delayed responses.
>>> These responses are processed after the "Checking out files" phase.
>>> If the processing takes noticeable time, then the user might think Git
>>> is stuck.
>>> 
>>> Display the progress of the delayed responses to let the user know that
>>> Git is still processing objects. This works very well for objects that
>>> can be filtered quickly. If filtering of an individual object takes
>>> noticeable time, then the user might still think that Git is stuck.
>>> However, in that case the user would at least know what Git is doing.
>>> 
>>> It would be technical more correct to display "Checking out files whose
>>> content filtering has been delayed". For brevity we only print
>>> "Filtering content".
>>> 
>>> The finish_delayed_checkout() call was moved below the stop_progress()
>>> call in unpack-trees.c to ensure that the "Checking out files" progress
>>> is properly stopped before the "Filtering content" progress starts in
>>> finish_delayed_checkout().
>>> 
>>> Signed-off-by: Lars Schneider <larsxschneider@xxxxxxxxx>
>>> Suggested-by: Taylor Blau <me@xxxxxxxxxxxx>
>>> ---
>> 
>> Makes sense.  The only thing that made me wonder was if we want the
>> change in unpack-trees.c in this patch.  After all, the procedure to
>> finish up the delayed checkout _is_ a part of the work need to be
>> done to populate the working tree files, so stopping the progress
>> before feels somewhat wrong at the phylosophical level.
>> 
>> I think our output cannot express nested progress bars, and I think
>> that is the reason why this patch tweaks unpack-trees.c; so I am
>> fine with the end result (and that is why I said "made me wonder
>> was", not "makes me wonder", the latter would imply "this we might
>> want fix before applying", but I do not think we want to change
>> anything this patch does to unpack-trees.c in this case).
>> 
>> The delayed progress API is being simplified so I'll probably do a
>> bit of evil merge while merging this to 'pu'.
>> 
>> Thanks.
> 
> Hi Junio,
> 
> I just realized that this patch got lost :-(
> That means 2.14.2 supports the delayed filters but does not show
> progress to the user. To the user Git will appear hanging.
> 
> Can you merge this this topic for 2.14.3 / 2.15 ?
> 
> Thank you,
> Lars

I should have expressed myself more clearly:
The patch made it into master with 52f1d62eb44faf569edca360ec9af9ddd4045fe0 .
Therefore, I think it will be released with 2.15, right?

The patch just did not make it into 2.14.2 and I wonder if you could
merge the patch for 2.14.3?

Thank you,
Lars




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux