From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Sebastian Gniazdowski" <psprint@zdharma.org>,
git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: Very simple popen() code request, ground-shaking functionality openned by it
Date: Fri, 21 Sep 2018 19:39:21 -0400 [thread overview]
Message-ID: <20180921233921.GA3323@sigill.intra.peff.net> (raw)
In-Reply-To: <87musajun7.fsf@evledraar.gmail.com>
On Sat, Sep 22, 2018 at 01:30:36AM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> This will allow users to free their creativity and provide probably
> >> dozens of custom Git progress bars.
> >
> > I don't personally feel that the existing progress bar is that bad, but
> > if anybody wants to pursue this, I think the most sensible path is:
>
> I don't think it's bad either, but one thing that's really neat about
> Sebastian's suggestion is that it's using some UTF-8 terminal ASCII art
> to render an actual progress bar.
Yeah. I don't care myself, but I'm not opposed to somebody trying to
spruce up the in-code bar, as long we can still handle the lowest common
denominator cleanly (and remember that includes passing progress bars
back over the remote sideband).
> > 1. Add a trace_key for sending machine-readable progress output to a
> > descriptor or file. E.g., via setting GIT_TRACE_PROGRESS=2 in the
> > environment.
> >
> > 2. Teach the trace code to open a command for piping, so that you
> > could do something like GIT_TRACE_PROGRESS='|mygauge'.
> >
> > That would make your use case work, and I think many other use cases
> > would benefit from both of those features independently.
>
> Yup, that's all sensible, and would be great both for this and other
> stuff if we wanted true extensibility for this sort of thing.
>
> I'll just add that a 3rd thing that would also make sense would be to
> add a feature to configure the value of these GIT_TRACE_*=* variables
> via the .gitconfig, that's been suggested before (too lazy to dig up a
> ML archive reference), and would make this as easy to configure as
> Sebastian's suggestion.
Heh, I almost included that in my original mail, but didn't want to get
into the tangle of secondary concerns. But since you mention it... :)
One thing to watch out is that (2) and (3) combined may mean executing
arbitrary code specified in the .git/config of an untrusted repository.
This is already the case for many commands, but we've specifically tried
to avoid it with git-upload-pack, making it safe to "git fetch" out of
an untrusted repository. It's almost certain that you'd be able to
trigger trace code from it.
There are a number of solutions floating around. We already have some
upload-pack config which is smart enough to realize when its source is
in-repo and handle it appropriately, and we've talked on the list about
having some "I don't trust this repo" environment variable that would
make Git operate in a more restricted way. I don't think we need to hash
out the solution here, but I just want to mention that it's a thing that
would have to dealt with before adding those two features.
(Actually, I guess you could argue that even reading existing trace
specs out of config is potentially dangerous, since you can append to
arbitrary files).
-Peff
next prev parent reply other threads:[~2018-09-21 23:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 13:34 Very simple popen() code request, ground-shaking functionality openned by it Sebastian Gniazdowski
2018-09-21 22:24 ` Jeff King
2018-09-21 23:30 ` Ævar Arnfjörð Bjarmason
2018-09-21 23:39 ` Jeff King [this message]
2018-09-22 18:16 ` Sebastian Gniazdowski
2018-09-23 13:06 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180921233921.GA3323@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=psprint@zdharma.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).