Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning
- From
Jeff King <peff@peff.net>
- Date
- Aug 25, 2015, 18:52 UTC
- Message-ID
- <20150825185210.GA10032@sigill.intra.peff.net>
- In-Reply-To
- <xmqqh9nnz08i.fsf@gitster.dls.corp.google.com>
On Tue, Aug 25, 2015 at 11:33:49AM -0700, Junio C Hamano wrote:
Show 5 quoted lines
> Jeff King <peff@peff.net> writes: > > > +start=$(date +%s) > > Is that a GNU extension?
Thanks, I meant to mention that, too. POSIX has "+" formats, but apparently no way to get an integer number of seconds. I don't know how widely "%s" is supported; BSD "date" seems to know about it.
Show 6 quoted lines
> An alternative implementation may be to ask `date` every 1000 > commits (or whatever sufficiently large value that we can amortise > the cost) to measure the rate and compute $remain based on that > measurement. That way, we can afford to use more portable ways to > ask `date` about the current time and compute the "how many seconds" > ourselves.
Yeah, that would probably be a good solution, assuming there is a portable "how many seconds" (I do not relish the thought of reconstructing it based on the current hours/minutes/seconds).
I wonder how awful it would be to make a tool like "git-progress", where you'd tell it "--total=$commits --eta" on the command line, and then occasionally print the current count its stdin. It might be a little painful to use, though. You'd want to background it with a pipe to its stdin, which is annoying without bash-style "<()" anonymous pipes.
-Peff