Hi,
On Tue, Dec 29, 2009 at 9:30 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Tay Ray Chuan <rctay89@xxxxxxxxx> writes:
>
>> On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin
>> <Johannes.Schindelin@xxxxxx> 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@xxxxxxxx>
Subject: Re: [Patch] Prevent cloning over http from spewing
Message-ID: <20090608115431.GC13775@xxxxxxxxxxxxxxxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html