Re: [PATCH v2] checkout: no progress messages if !isatty(2).
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- May 24, 2012, 18:49 UTC
- 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:
Show 15 quoted lines
> 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