From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Trieu Huynh <vikingtc4@gmail.com>, git@vger.kernel.org
Subject: Re: [GSoC PATCH] backfill: add --[no-]progress option
Date: Mon, 06 Apr 2026 10:35:58 -0700 [thread overview]
Message-ID: <xmqqh5poat4x.fsf@gitster.g> (raw)
In-Reply-To: <8db10441-2fce-43ad-bcdc-331d26ec38ed@gmail.com> (Derrick Stolee's message of "Mon, 6 Apr 2026 09:16:30 -0400")
Derrick Stolee <stolee@gmail.com> writes:
> On 3/29/2026 11:24 AM, Trieu Huynh wrote:
>> 'git backfill' is silent when downloading missing objects, giving
>> no feedback during potentially long-running operations on large
>> repositories. By contrast, 'git fetch', 'git gc', and
>> 'git index-pack' all support --[no-]progress.
>
> I wouldn't use the word "silent" because the output is actually
> quite verbose by default.
;-)
> With your patch, I think there would be some extra progress
> indicators between these batched fetch requests.
>> static void backfill_context_clear(struct backfill_context *ctx)
>> @@ -54,6 +57,7 @@ static void download_batch(struct backfill_context *ctx)
>> * avoid possible duplicate downloads of the same objects.
>> */
>> odb_reprepare(ctx->repo->objects);
>> + display_progress(ctx->progress, ++ctx->batches_requested);
>
> This looks correct. My preference is to not use prefix operators
> like this on struct members (it reads like you are incrementing
> 'ctx' and not 'batches_requested', even though it is correct).
Thanks for paying extra attention to such details. In general,
post-increment and pre-decrement are the norm when evaluated in a
void context, so the use of pre-increment above violates that norm
too.
> However, I'm not sure that we want the progress to indicate the
> number of _batches_ but instead should be the number of _objects_.
True, too.
Thanks.
next prev parent reply other threads:[~2026-04-06 17:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-29 15:24 [GSoC PATCH] backfill: add --[no-]progress option Trieu Huynh
2026-04-06 13:16 ` Derrick Stolee
2026-04-06 17:35 ` Junio C Hamano [this message]
2026-04-07 19:22 ` Trieu Huynh
2026-04-07 19:42 ` Junio C Hamano
2026-04-07 19:15 ` Trieu Huynh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh5poat4x.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=stolee@gmail.com \
--cc=vikingtc4@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.