Re: git fetch -v not at all verbose?

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Jan 21, 2010 at 08:57:37AM -0800, Shawn O. Pearce wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Thu, Jan 21, 2010 at 08:18:58AM -0800, Shawn O. Pearce wrote:
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > On many of my trees (with linux kernel), git fetch is slower than git clone.
> > > > Even more annoyingly, it would hang sometimes for tens of minutes without any
> > > > output, even if -v is supplied.
> ...
> > > Given the symptom, it sounds to me like your local repository
> > > is some 1,000s of commits ahead of the remote repository you are
> > > fetching from.  Is that true?
> > 
> > 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?
> 
> Yes.
> 
> > > Are you fetching from a configured remote that has tracking branches,
> > > or are you fetching through a one-shot URL pasted onto the command
> > > line?
> > 
> > Configured remote.
> 
> 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?

> -- 
> Shawn.