{"thread":{"id":"49397","subject":"Very simple popen() code request, ground-shaking functionality openned by it","startedAt":"2018-09-21T13:48:54Z","lastAt":"2018-09-23T13:07:24Z","messageCount":6,"participants":["Sebastian Gniazdowski","Jeff King","Ævar Arnfjörð Bjarmason","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"358565","messageId":"315083291.15466.1537536854535@privateemail.com","threadId":"49397","inReplyTo":null,"subject":"Very simple popen() code request, ground-shaking functionality openned by it","fromName":"Sebastian Gniazdowski","fromEmail":"psprint@zdharma.org","sentAt":"2018-09-21T13:34:14Z","receivedAt":"2018-09-21T13:48:54Z","isPatch":false,"sender":{"key":"psprint@zdharma.org","avatar":null},"body":"Hello!\n\nGit 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!\n\nHave a look at my gauge box constructed as git-stderr pipe script: https://asciinema.org/a/202401\n\nThe 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.\n\nThis will allow users to free their creativity and provide probably dozens of custom Git progress bars.\n\n--\n\nBest regards,\nSebastian Gniazdowski\nBlog: http://zdharma.org\n"},{"id":"358670","messageId":"20180921222454.GD11177@sigill.intra.peff.net","threadId":"49397","inReplyTo":"315083291.15466.1537536854535@privateemail.com","subject":"Re: Very simple popen() code request, ground-shaking functionality openned by it","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-21T22:24:54Z","receivedAt":"2018-09-21T22:24:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 21, 2018 at 09:34:14AM -0400, Sebastian Gniazdowski wrote:\n\n> Git default progress indicator for clone is very unattractive, IMO. It\n> does its job in providing all the operation details very well, but I\n> bet most of users strongly dream about a gauge box!\n> \n> Have a look at my gauge box constructed as git-stderr pipe script:\n> https://asciinema.org/a/202401\n> \n> The main point of my feature request is: git can add\n> core.progress_pipe option, where e.g. `/usr/local/bin/mygauge' will be\n> set (a script like the one in the asciinema), and then simply do the\n> ground-school-known `popen(\"/usr/local/bin/mygauge\",\"r+\")', and write\n> **unchanged current-progress data** to the pipe, then read from the\n> pipe and forward to `stderr', where the progress normally lands in.\n> \n> This will allow users to free their creativity and provide probably\n> dozens of custom Git progress bars.\n\nI don't personally feel that the existing progress bar is that bad, but\nif anybody wants to pursue this, I think the most sensible path is:\n\n  1. Add a trace_key for sending machine-readable progress output to a\n     descriptor or file. E.g., via setting GIT_TRACE_PROGRESS=2 in the\n     environment.\n\n  2. Teach the trace code to open a command for piping, so that you\n     could do something like GIT_TRACE_PROGRESS='|mygauge'.\n\nThat would make your use case work, and I think many other use cases\nwould benefit from both of those features independently.\n\n-Peff\n"},{"id":"358684","messageId":"87musajun7.fsf@evledraar.gmail.com","threadId":"49397","inReplyTo":"20180921222454.GD11177@sigill.intra.peff.net","subject":"Re: Very simple popen() code request, ground-shaking functionality openned by it","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-21T23:30:36Z","receivedAt":"2018-09-21T23:30:43Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Sep 21 2018, Jeff King wrote:\n\n> On Fri, Sep 21, 2018 at 09:34:14AM -0400, Sebastian Gniazdowski wrote:\n>\n>> Git default progress indicator for clone is very unattractive, IMO. It\n>> does its job in providing all the operation details very well, but I\n>> bet most of users strongly dream about a gauge box!\n>>\n>> Have a look at my gauge box constructed as git-stderr pipe script:\n>> https://asciinema.org/a/202401\n>>\n>> The main point of my feature request is: git can add\n>> core.progress_pipe option, where e.g. `/usr/local/bin/mygauge' will be\n>> set (a script like the one in the asciinema), and then simply do the\n>> ground-school-known `popen(\"/usr/local/bin/mygauge\",\"r+\")', and write\n>> **unchanged current-progress data** to the pipe, then read from the\n>> pipe and forward to `stderr', where the progress normally lands in.\n>>\n>> This will allow users to free their creativity and provide probably\n>> dozens of custom Git progress bars.\n>\n> I don't personally feel that the existing progress bar is that bad, but\n> if anybody wants to pursue this, I think the most sensible path is:\n\nI don't think it's bad either, but one thing that's really neat about\nSebastian's suggestion is that it's using some UTF-8 terminal ASCII art\nto render an actual progress bar.\n\nIt would be very cool if we had some \"we can use non-ASCII for such art\"\ncore.* option, similar to how we pushed the boundaries with what was\nacceptable with pagers and having colors on by default (and perhaps we\ncould even turn such a non-ASCII mode on by default eventually...).\n\nDuy's\nhttps://public-inbox.org/git/20180920161928.GA13379@duynguyen.home/ is\nanother recent thing that reminded me of this, i.e. that suggested\n\"\\\\|/-\" spinner could be made much neater with non-ASCII.\n\n>   1. Add a trace_key for sending machine-readable progress output to a\n>      descriptor or file. E.g., via setting GIT_TRACE_PROGRESS=2 in the\n>      environment.\n>\n>   2. Teach the trace code to open a command for piping, so that you\n>      could do something like GIT_TRACE_PROGRESS='|mygauge'.\n>\n> That would make your use case work, and I think many other use cases\n> would benefit from both of those features independently.\n\nYup, that's all sensible, and would be great both for this and other\nstuff if we wanted true extensibility for this sort of thing.\n\nI'll just add that a 3rd thing that would also make sense would be to\nadd a feature to configure the value of these GIT_TRACE_*=* variables\nvia the .gitconfig, that's been suggested before (too lazy to dig up a\nML archive reference), and would make this as easy to configure as\nSebastian's suggestion.\n"},{"id":"358686","messageId":"20180921233921.GA3323@sigill.intra.peff.net","threadId":"49397","inReplyTo":"87musajun7.fsf@evledraar.gmail.com","subject":"Re: Very simple popen() code request, ground-shaking functionality openned by it","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-21T23:39:21Z","receivedAt":"2018-09-21T23:39:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 22, 2018 at 01:30:36AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> >> This will allow users to free their creativity and provide probably\n> >> dozens of custom Git progress bars.\n> >\n> > I don't personally feel that the existing progress bar is that bad, but\n> > if anybody wants to pursue this, I think the most sensible path is:\n> \n> I don't think it's bad either, but one thing that's really neat about\n> Sebastian's suggestion is that it's using some UTF-8 terminal ASCII art\n> to render an actual progress bar.\n\nYeah. I don't care myself, but I'm not opposed to somebody trying to\nspruce up the in-code bar, as long we can still handle the lowest common\ndenominator cleanly (and remember that includes passing progress bars\nback over the remote sideband).\n\n> >   1. Add a trace_key for sending machine-readable progress output to a\n> >      descriptor or file. E.g., via setting GIT_TRACE_PROGRESS=2 in the\n> >      environment.\n> >\n> >   2. Teach the trace code to open a command for piping, so that you\n> >      could do something like GIT_TRACE_PROGRESS='|mygauge'.\n> >\n> > That would make your use case work, and I think many other use cases\n> > would benefit from both of those features independently.\n> \n> Yup, that's all sensible, and would be great both for this and other\n> stuff if we wanted true extensibility for this sort of thing.\n> \n> I'll just add that a 3rd thing that would also make sense would be to\n> add a feature to configure the value of these GIT_TRACE_*=* variables\n> via the .gitconfig, that's been suggested before (too lazy to dig up a\n> ML archive reference), and would make this as easy to configure as\n> Sebastian's suggestion.\n\nHeh, I almost included that in my original mail, but didn't want to get\ninto the tangle of secondary concerns. But since you mention it... :)\n\nOne thing to watch out is that (2) and (3) combined may mean executing\narbitrary code specified in the .git/config of an untrusted repository.\nThis is already the case for many commands, but we've specifically tried\nto avoid it with git-upload-pack, making it safe to \"git fetch\" out of\nan untrusted repository. It's almost certain that you'd be able to\ntrigger trace code from it.\n\nThere are a number of solutions floating around. We already have some\nupload-pack config which is smart enough to realize when its source is\nin-repo and handle it appropriately, and we've talked on the list about\nhaving some \"I don't trust this repo\" environment variable that would\nmake Git operate in a more restricted way. I don't think we need to hash\nout the solution here, but I just want to mention that it's a thing that\nwould have to dealt with before adding those two features.\n\n(Actually, I guess you could argue that even reading existing trace\nspecs out of config is potentially dangerous, since you can append to\narbitrary files).\n\n-Peff\n"},{"id":"358711","messageId":"etPan.5ba686e3.762c4412.1ba0@zdharma.org","threadId":"49397","inReplyTo":"87musajun7.fsf@evledraar.gmail.com","subject":"Re: Very simple popen() code request, ground-shaking functionality openned by it","fromName":"Sebastian Gniazdowski","fromEmail":"psprint@zdharma.org","sentAt":"2018-09-22T18:16:03Z","receivedAt":"2018-09-22T18:16:10Z","isPatch":false,"sender":{"key":"psprint@zdharma.org","avatar":null},"body":"On 22 września 2018 at 01:30:36, Ævar Arnfjörð Bjarmason (avarab@gmail.com) wrote: \n> Duy's  \n> https://public-inbox.org/git/20180920161928.GA13379@duynguyen.home/ is  \n> another recent thing that reminded me of this, i.e. that suggested  \n> \"\\\\|/-\" spinner could be made much neater with non-ASCII.  \n\nHere is a IMO very large collection of spinner-like unicode animations: \n\nhttps://asciinema.org/a/ex8z3z6d5m7uv4buww0o2qeq2 \n\nThis comes from Zsh world, it's a plugin with spinners to use in Zsh scripts. I've never managed to see even 1/3 of them. \n\n> I'll just add that a 3rd thing that would also make sense would be to  \n> add a feature to configure the value of these GIT_TRACE_*=* variables  \n> via the .gitconfig, that's been suggested before (too lazy to dig up a  \n> ML archive reference), and would make this as easy to configure as  \n> Sebastian's suggestion.  \n\nYes git config setting of this is most convenient IMO, most expected to occur in ~/.gitconfig, in which it would be set once to a favourite gauge-box script, and rather long long before looking at this part of config again. Or maybe in the beginning, dawn of such gauge-scripts (if there actually would be any new group of such scripts; but as it's a quite broad problem (see last `PS.' paragraph), then who knows), when some unstable gauge-box would be breaking login/passwords prompt (but that's stdout not stderr, shouldn't go through gauge-box-script) or \"fatal: ...\" messages, etc., user might be disabling it temporarily or choosing an alternate gauge-box solution, editing the config option ;) So not rarely edited in the beginning. (I don't know how much important would a fancy gauge box be for a regular user; I can tell it would be quite important to me). I think this is more convenient and clean than `export GIT_*' in .bashrc/.zshrc, rarely edited, just sitting there. \n\nGuys you seem to like the idea, I hope someone will approach the coding! \n\nPS. There's much room for improvement in the git-process-output.zsh in the Asciinema video, gauge scripts won't be simple. In general, the number of 0..100% sequences (like: compressing, resolving, etc. – they all go 0 to 100% on their own) should be somehow predicted (does Git know this in advance?) and the gauge should be divided into that many segments, each filling up per one corresponding 0..100% sequence, together forming single global 0..100% gauge.\n\n--  \nSebastian Gniazdowski \nNews: https://twitter.com/ZdharmaI \nIRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin \nBlog: http://zdharma.org\n"},{"id":"358720","messageId":"CACsJy8C5-kFivA5eEJu7pKA5=PajW5rLB6V4tVEueMtr58QC=A@mail.gmail.com","threadId":"49397","inReplyTo":"87musajun7.fsf@evledraar.gmail.com","subject":"Re: Very simple popen() code request, ground-shaking functionality openned by it","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-09-23T13:06:56Z","receivedAt":"2018-09-23T13:07:24Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Sep 22, 2018 at 1:30 AM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> Duy's\n> https://public-inbox.org/git/20180920161928.GA13379@duynguyen.home/ is\n> another recent thing that reminded me of this, i.e. that suggested\n> \"\\\\|/-\" spinner could be made much neater with non-ASCII.\n>\n> >   1. Add a trace_key for sending machine-readable progress output to a\n> >      descriptor or file. E.g., via setting GIT_TRACE_PROGRESS=2 in the\n> >      environment.\n> >\n> >   2. Teach the trace code to open a command for piping, so that you\n> >      could do something like GIT_TRACE_PROGRESS='|mygauge'.\n> >\n> > That would make your use case work, and I think many other use cases\n> > would benefit from both of those features independently.\n>\n> Yup, that's all sensible, and would be great both for this and other\n> stuff if we wanted true extensibility for this sort of thing.\n>\n> I'll just add that a 3rd thing that would also make sense would be to\n> add a feature to configure the value of these GIT_TRACE_*=* variables\n> via the .gitconfig, that's been suggested before (too lazy to dig up a\n> ML archive reference), and would make this as easy to configure as\n> Sebastian's suggestion.\n\nI'm less concern about prettiness than showing numbers that are hard\nto interpret. My other option was just showing \".\", \"..\", \"...\"\nsequence, which achieves the same thing.\n\nI'm not opposed to having core.progressor or something like that. We\nalready have core.pager and this new config serves more or less the\nsame purpose. But I don't think I'll put time into implementing it.\n\n-- \nDuy\n"}]}