Re: [PATCH] filter-branch: add passed/remaining seconds on progress

On Tue, Sep 22, 2015 at 6:08 PM, Junio C Hamano <gits...@pobox.com> wrote: > Gabor Bernat <ber...@primeranks.net> writes: > >> On Mon, Sep 21, 2015 at 11:24 PM, Gábor Bernát >> ... >>> Agreed, :) did not abandoned this, just got caught up with many stuff.

Re: [PATCH] filter-branch: add passed/remaining seconds on progress

On Mon, Sep 21, 2015 at 11:24 PM, Gábor Bernát wrote: > On Mon, Sep 21, 2015 at 11:22 PM, Eric Sunshine > wrote: >> >> On Mon, Sep 21, 2015 at 3:52 PM, Junio C Hamano wrote: >> > Eric Sunshine

Re: [PATCH] filter-branch: add passed/remaining seconds on progress

On Fri, Sep 4, 2015 at 10:15 PM, Eric Sunshine wrote: > On Fri, Sep 4, 2015 at 2:34 PM, Junio C Hamano wrote: >> Gábor Bernát writes: >>> +echo $(date +%s) | grep -q '^[0-9]+$'; 2>/dev/null && show_seconds=t >> >> That is very

Add passed and estimated seconds to the filter-branch on demand via --progress-eta flag

. Here follows a patch, I really hope I got right the format: From 620e69d10a1bfcfcace347cbb95991d75fd23a1d Mon Sep 17 00:00:00 2001 From: Gabor Bernat gabor.ber...@gravityrd.com Date: Thu, 27 Aug 2015 00:46:52 +0200 Subject: [PATCH] Add to the git filter-branch a --progress-eta flag which when

Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

, 2015 at 5:15 AM, Eric Sunshine sunsh...@sunshineco.com wrote: (Please don't top-post on this list.) On Sat, Aug 29, 2015 at 11:00 PM, Gabor Bernat ber...@primeranks.net wrote: Reading after it, I think the most close we can get with this is, awk 'BEGIN { print strftime(%c, 1271603087

Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

I would argue against the every n commit check, or at least making it configurable, as in my case the speed is something between 0.01 and 1.5 seconds per commit. Checking it every n commit would make it I feel quite slow to adapt. But it's debatable. On 8/30/15, Junio C Hamano gits...@pobox.com

Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

Hello, Here's what I ended up using, and seemed to work well: https://github.com/gaborbernat/git/commit/766841bc1b726a5d6e7e051938b82975368695a0 Does this looks okay, should I create a patch from this? Thanks, Bernát GÁBOR On Wed, Aug 26, 2015 at 4:15 AM, Jeff King p...@peff.net wrote: On

Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

Amended, the latest version is at https://github.com/gaborbernat/git/commit/ :) Bernát GÁBOR On Sat, Aug 29, 2015 at 11:50 AM, Gabor Bernat ber...@primeranks.net wrote: Hello, Here's what I ended up using, and seemed to work well: https://github.com/gaborbernat/git/commit

Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

wrote: On Sat, Aug 29, 2015 at 9:29 AM, Gabor Bernat ber...@primeranks.net wrote: Amended, the latest version is at https://github.com/gaborbernat/git/commit/ :) Does this looks okay, should I create a patch from this? Excerpt: now=$(date +%s) elapsed=$(($now - $start

[FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

Hello, So it would be great if the filter-branch beside the Rewrite f8f0b351ae35ff7ac4bd58078cbba1aa34243779 (523/22625), would also append a basic ETA signaling the end of the operation. It could be as simple as the the average number of milliseconds per step up to this point multiplied with

Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

I would lean for an extra on-demand flag for this, and a per commit measurement, initial noise is okay for the first iteration I think. Secondly note that on the output other messages could also be present (other than the rewrite), as the command running may have its own output. I will try to