Re: [PATCH 0/4] clone: use --progress to mean -v

[Tay Ray Chuan <rctay89@gmail.com>]

Hi,

On Tue, Dec 29, 2009 at 9:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> On Sat, 26 Dec 2009, Tay Ray Chuan wrote:
>>>
>>>> This series makes git-clone follow the "argument convention" of
>>>> git-pack-objects, where the option --progress is used to force reporting
>>>> of reporting. This was previously done with -v/--verbose.
>>>
>>> No objections from my side, although you might want to advertise more that
>>> this is a change in behavior.  (Meaning in the release notes)
>>
>> Indeed, -v/--verbose to force reporting of progress was done sometime
>> last year (Thu Oct 9 2008) so there may be scripts/applications
>> dependent on this option.
>>
>> Junio, do you have any advice on this front?
>
> [1/4] sounds like a sane thing to do regardless of the remainder of the
> series, as stderr is where we write the progress output anyway. [2/4]
> looks trivially correct.
>
> It is unclear what impact [3/4] has.  I can read "With this patch,
> transport can pay attention to the verbose option given from the end user
> and act more verbosely, which was not something they couldn't do before",
> but what is the practical difference our existing users would see?  IOW,
> which transports are silent without this patch even when the user gives -v
> from the command line?

I know at least one transport which behaves in this manner (ie. silent
even when -v is supplied to git-clone), and that is the http (via
curl) transport.

> I however wonder if it is of lessor impact if we only added --progress
> but without removing the progress from -v.  Is there a downside?

(Just to clarify: progress reporting will be done if stderr is a
terminal - it will be done even if -v or --progress isn't present.
What -v/--progress does is force progress reporting even if stderr is
not a terminal.)

Leaving -v as it is (ie. forcing progress reporting) while adding
--progress would be a "safe" option, as it won't break people's
existing setups (ie. those that depend on -v to force progress
reporting), which the patch series does. I have in mind IDEs/editors
that use this behaviour to monitor progress.

On the other hand, if we decide -v shouldn't imply forcing progress
reporting, then I think this breakable change should be made soon,
when only a small minority of git commands are affected (only one,
git-clone). That way, we don't give users/integrators the impression
that -v forces progress reporting with git commands. They won't get
annoyed when try -v to force progress reporting and find that it isn't
the case.

By the way, I got this "-v doesn't imply forced progress reporting"
rule from Jeff (added to Cc list), who mentioned it some time ago:

  Date: Mon, 8 Jun 2009 07:54:31 -0400
  From: Jeff King <peff@peff.net>
  Subject: Re: [Patch] Prevent cloning over http from spewing
  Message-ID: <20090608115431.GC13775@coredump.intra.peff.net>

  I was imagining:

    - without "-q", show progress if isatty(1).

    - with "-q", never show progress

    - with "-v", show the "getting pack" and "walk" output we show now;
      without "-v", don't show it. "-v" has no impact on the progress
      indicator.

-- 
Cheers,
Ray Chuan