Re: git fetch -v not at all verbose?
- From
- Michael S. Tsirkin <mst@redhat.com>
- Date
- Jan 21, 2010, 17:30 UTC
- Message-ID
- <20100121173010.GB16707@redhat.com>
- In-Reply-To
- <20100121165737.GG19078@spearce.org>
On Thu, Jan 21, 2010 at 08:57:37AM -0800, Shawn O. Pearce wrote:
Show 25 quoted lines
> "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.