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

From: Taylor Blau <me@ttaylorr.com>
Date: Mar 2, 2022, 22:55 UTC
Message-ID: <Yh/1zFChEXz7r1vN@nand.local>
In-Reply-To: <220302.865yow6u8a.gmgdl@evledraar.gmail.com>

On Wed, Mar 02, 2022 at 08:00:59PM +0100, Ævar Arnfjörð Bjarmason wrote:

> So please have this by "int progress = 1", and have a "PARSE_OPT_NONEG"
> "no-progress" option instead, there's no reason we need to propagate the
> existing UX mistake in "reflog expire".

Yes, I agree that `git remote` is unlike other commands where you have to opt _in_ to see progress, not out.

But I deliberately avoided doing anything about it here, since this patch is more about making an existing set of arguments (`git remote -v rename`) do something more useful than before, and not adding a new option.

In other words, I felt that because you could already run:

    $ git remote -v rename old new

that it was better to punt on any changes to the option itself until later.

On a similar note, it would be nice if this option worked on either side of the sub-command, like how you can do either of:

    $ git multi-pack-index --object-dir=... write
    $ git multi-pack-index write --object-dir=...

But I don't think we should let perfect be the enemy of the good here, in case you were suggesting delaying this patch until we sort that issue out.

> [I reversed the order you wrote the following, due to the obvious
> digression...] :)

;-), thanks.

> As an aside I think the reftable code "emulates" the D/F conflicts of
> the files backend, but I'm not sure (this is from vague memory).

Perhaps, though I'm admittedly not familiar enough with that work to tell know for sure, either. I don't think I have a ton to add to the lower part of your reply, so I'll stop here.

Thanks, Taylor