On Fri, Sep 21 2018, Jeff King wrote: > On Fri, Sep 21, 2018 at 09:34:14AM -0400, Sebastian Gniazdowski wrote: > >> Git default progress indicator for clone is very unattractive, IMO. It >> does its job in providing all the operation details very well, but I >> bet most of users strongly dream about a gauge box! >> >> Have a look at my gauge box constructed as git-stderr pipe script: >> https://asciinema.org/a/202401 >> >> The main point of my feature request is: git can add >> core.progress_pipe option, where e.g. `/usr/local/bin/mygauge' will be >> set (a script like the one in the asciinema), and then simply do the >> ground-school-known `popen("/usr/local/bin/mygauge","r+")', and write >> **unchanged current-progress data** to the pipe, then read from the >> pipe and forward to `stderr', where the progress normally lands in. >> >> 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. It would be very cool if we had some "we can use non-ASCII for such art" core.* option, similar to how we pushed the boundaries with what was acceptable with pagers and having colors on by default (and perhaps we could even turn such a non-ASCII mode on by default eventually...). Duy's https://public-inbox.org/git/20180920161928.GA13379@xxxxxxxxxxxxxx/ is another recent thing that reminded me of this, i.e. that suggested "\\|/-" spinner could be made much neater with non-ASCII. > 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.
