From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 25 Aug 2015 18:33:49 GMT
Subject: Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning
Message-ID: <xmqqh9nnz08i.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150825171238.GB9674@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> +start=$(date +%s)

Is that a GNU extension?

>  git_filter_branch__commit_count=0
>  while read commit parents; do
>  	git_filter_branch__commit_count=$(($git_filter_branch__commit_count+1))
> -	printf "\rRewrite $commit ($git_filter_branch__commit_count/$commits)"
> +	now=$(date +%s)
> +	elapsed=$(($now - $start))
> +	# work in integer percentages as a sort of fixed-point
> +	pct=$(($git_filter_branch__commit_count * 100 / $commits))
> +	if test $pct -eq 0; then
> +		remain=
> +	else
> +		eta=$(($elapsed * 100 / $pct))
> +		remain="($(($eta - $elapsed)) seconds remaining)   "
> +	fi
> +	printf "\rRewrite $commit ($git_filter_branch__commit_count/$commits) $remain"
>  
>  	case "$filter_subdir" in
>  	"")
>
> but the time jumps around early on because of the lack of precision. And
> of course there's no smoothing, and no emphasis on recent history versus
> the whole operation. I'll leave those as an exercise to the reader. :)

;-)

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.