Re: [PATCH] builtin/remote.c: show progress when renaming remote references

From: Derrick Stolee <derrickstolee@github.com>
Date: Mar 3, 2022, 16:09 UTC
Message-ID: <95207e46-defb-f36e-ea3c-a2454c15bd8e@github.com>
In-Reply-To: <Yh/2Pkc493ABWv46@nand.local>

On 3/2/2022 5:57 PM, Taylor Blau wrote:

Show 15 quoted lines

> On Wed, Mar 02, 2022 at 10:21:16PM +0000, brian m. carlson wrote:
>> For context, I discovered this when I tried to rename a remote with tens
>> of thousands of branches and it just ran silently for an extended period
>> of time without any output.  I actually interrupted it with Ctrl-C
>> because I thought it had hung, so I'm hoping this will provide a better
>> experience for users in that situation.
> 
> Thanks again for pointing it out to me. To be honest, I'm skeptical that
> this patch alone will improve things much, since you still have to pass
> the '-v' flag to see the new progress meter.
> 
> But perhaps users who suspect the command is hung will re-run it with
> the '-v' flag instinctually and get more helpful output. I'll look at
> making `git remote`'s `-v` behave a little more like `--[no-]progress'
> in another series.

I guess one big reason for Ævar's suggestion about using --[no-]progress as the signal for progress is that we can make --progress the default when isatty(2) is true. We should not do the same for --verbose.

Looking at other examples, I see that 'fsck' has --verbose imply --no-progress, probably because the verbose output would write lines that become interleaved with the progress indicators (and those lines act as progress in themselves). Not sure if that's the right choice in this case, too.

Thanks, -Stolee