Re: git fetch -v not at all verbose?

From: Thomas Rast <trast@student.ethz.ch>
Date: Jan 21, 2010, 17:47 UTC
Message-ID: <201001211847.40003.trast@student.ethz.ch>
In-Reply-To: <20100121173010.GB16707@redhat.com>

On Thursday 21 January 2010 18:30:10 Michael S. Tsirkin wrote:

Show 5 quoted lines

> On Thu, Jan 21, 2010 at 08:57:37AM -0800, Shawn O. Pearce wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > Hmm, no, but what is true is that I fetched several remotes
> > > that diverged significantly into the same local repository.
> > > Would that have same effect?

[...]

Show 7 quoted lines

> > Hmm.  I wonder if we should try to shortcut the commit walking in
> > a case like this and just feed the tracking branches we already have.
> 
> Or for the case of 1,000s of commits ahead, git could try to implement a
> heuristic to reduce the number of commits sent. Currently all commits
> are sent in order, correct?  How about binary search like what git
> bisect does?

I had a patch for this ages ago (that combines exponential-stride backwards search and later bisection), but it was shot down on grounds of not working at times and code convolution and I forgot about it...

I can give this another shot, but it seems most of the code has moved due to the transport handlers changes, so I'll first have to read into it again.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch