From: Derrick Stolee <stolee@gmail.com>
To: Trieu Huynh <vikingtc4@gmail.com>, gitster@pobox.com
Cc: git@vger.kernel.org
Subject: Re: [GSoC PATCH v2] backfill: add --[no-]progress option
Date: Sun, 12 Apr 2026 15:46:17 -0400 [thread overview]
Message-ID: <d2cf741c-a381-42a6-9d26-e38481696adb@gmail.com> (raw)
In-Reply-To: <20260412193659.26288-1-viking4@gmail.com>
On 4/12/26 3:36 PM, Trieu Huynh wrote:
> From: Trieu Huynh <vikingtc4@gmail.com>
>
> 'git backfill' does not show an overall progress bar across
> batches, giving no cross-batch feedback during potentially
> long-running operations on large repositories. By contrast,
> 'git fetch', 'git gc', and 'git index-pack' all support
> --[no-]progress.
>
> Add a --[no-]progress option that tracks the total number of
> missing blobs downloaded across all batches, defaulting to
> showing progress when stderr is a terminal (matching the
> behaviour of 'git fetch').
>
> Add tests to verify that:
> - progress is shown by default on a TTY
> - --progress forces output regardless of TTY
> - --no-progress suppresses output
I think the tests do show an improvement, but we're missing
the interaction with the underlying fetch's progress
indicators. I don't see any mention of how your backfill
progress indicators will work with or against the fetch's
progress from the remote and index-pack steps.
Further, if a user supplies 'git backfill --no-progress'
then they are probably saying "I don't want any progress
indicators" and that would signal also that the fetch should
be quiet. This is perhaps the key detail that makes your
current version unable to move forward. It creates an
implication that it doesn't follow-through on.
One way to go about this is to hide the 'git fetch' output
entirely by passing '--quiet' unconditionally from the
backfill command. But this may also be too much for users
who want to watch the download statistics from the remote.
Perhaps a way to have a robust set that allows all things
to interact is to do the following:
1. Add a --[no-]verbose option that is off by default. The
implementation sends the --quiet flag to 'git fetch' if
--verbose isn't provided from the user. This reduces the
noise for the default user.
2. Add a --[no-]progress option as you've provided here.
The complexity at the end is about what happens when the
user provides both --verbose and --progress, which is the
situation that this patch is currently in. How do the
progress indicators mingle with the verbose fetch output?
Thanks,
-Stolee
next prev parent reply other threads:[~2026-04-12 19:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-12 19:36 [GSoC PATCH v2] backfill: add --[no-]progress option Trieu Huynh
2026-04-12 19:46 ` Derrick Stolee [this message]
2026-04-13 19:02 ` Trieu Huynh
2026-04-15 18:28 ` Derrick Stolee
2026-04-15 17:04 ` Tian Yuchen
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=d2cf741c-a381-42a6-9d26-e38481696adb@gmail.com \
--to=stolee@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox