From: Avery Pennarun <apenwarr@gmail.com>
Date: Thu, 24 May 2012 18:49:40 GMT
Subject: Re: [PATCH v2] checkout: no progress messages if !isatty(2).
Message-ID: <CAHqTa-0y0ETeq2G2FPMWgAwkXF_LSLN=VqnijF-m3q2YT0z4mQ@mail.gmail.com>
In-Reply-To: <20120524183457.GA11841@sigill.intra.peff.net>

On Thu, May 24, 2012 at 2:34 PM, Jeff King <peff@peff.net> wrote:
> On Thu, May 24, 2012 at 11:29:52AM -0700, Junio C Hamano wrote:
>> I do not seem to find a sane justification for
>>
>>       git $cmd --progress 2>output
>>
>> use case and I do not immediately see how that "output" file can be
>> useful.  But we've allowed it for a long time, so probably this version is
>> safer.  Besides, it is more explicit.
>
> Actually, I ran across a case of this just recently. If you are writing
> a graphical interface that wraps git, scraping "--progress" output from
> a pipe is the only way you can provide a progress meter within your
> interface. That is what the "GitHub for {Mac,Windows}" interfaces do
> (they also use libgit2 where possible, but it is far from feature
> complete).

This is why we have ptys, isn't it? :)

</halfkidding>

FWIW, in bup we use environment variables for this.  bup's main
program automatically redirects stderr to a pipe (to keep overlapping
status messages from interfering with each other) and the subcommands
need to know that stderr "was" a tty.  Arguably, an environment
variable is a better place for this since a script would presumably
want progress messages or not, globally.  It would also have solved
the problem where git-new-worktree doesn't have a --quiet option.

Have fun,

Avery