From: Tay Ray Chuan Date: Tue, 29 Dec 2009 03:06:29 GMT Subject: Re: [PATCH 0/4] clone: use --progress to mean -v Message-ID: In-Reply-To: <7vljgmpnxj.fsf@alter.siamese.dyndns.org> Hi, On Tue, Dec 29, 2009 at 9:30 AM, Junio C Hamano wrote: > Tay Ray Chuan writes: > >> On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin >> 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 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