On Thu, May 24, 2012 at 2:34 PM, Jeff King <peff@xxxxxxxx> 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
--
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