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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2015, 18:33 UTC
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?

Show 22 quoted lines

>  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.