On 12/15/2017 1:30 PM, Junio C Hamano wrote:
Derrick Stolee writes:
The biggest reason for the 20 seconds is not just the number of
commits in the ahead/behind but how many commits are walked (including
common to both branches) before paint_down_to_common() breaks its
while
Derrick Stolee writes:
> The biggest reason for the 20 seconds is not just the number of
> commits in the ahead/behind but how many commits are walked (including
> common to both branches) before paint_down_to_common() breaks its
> while loop due to queue_has_nonstale().
Hmm,
On 12/15/2017 10:08 AM, Jeff Hostetler wrote:
On 12/15/2017 5:08 AM, Jeff King wrote:
On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote:
[*] Sadly, the local repo was only about 20 days out of
date (including the Thanksgiving holidays)
Taking 20 seconds to traverse 20
On 12/15/2017 5:08 AM, Jeff King wrote:
On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote:
I don't want to jump into the graph algorithm at this time,
but was wondering about adding a --no-ahead-behind flag (or
something similar or a config setting) that would disable
the a/b
On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote:
> I don't want to jump into the graph algorithm at this time,
> but was wondering about adding a --no-ahead-behind flag (or
> something similar or a config setting) that would disable
> the a/b computation during status.
>
> For
We working with the (enormous) Windows repo, we observed
a performance problem in the ahead-behind computation and
were considering a few options.
We had a local repo with a local branch that was 150K
commits behind the upstream branch[*]. There was a ~20
second different in the run times for
6 matches
Mail list logo