Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 28, 2006, 08:17 UTC
Message-ID: <20061228081701.GA18029@spearce.org>
In-Reply-To: <7v8xgsxx1r.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 13 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Users may also now use `git-pull . foo~3` to merge the early part
> > of branch foo.  This was not previously possible as git-fetch does
> > not know how to fetch foo~3 from a repository.
> 
> I personally think this is not an improvement, but rather a new
> source of confusion.  If the user wants a local merge, there is
> 'git-merge'.  And the distinction between the commands makes it
> clear that local merge can merge any commits exactly because
> they are available locally, while remote fetch+merge needs to
> choose from what the remote side offers so not arbitrary commits
> like foo@{3.days.ago} cannot be pulled.

True. But you know you are doing a local merge with `git pull .`. So why should you be restricted from using the capabilities of a local merge just because the frontend you prefer to use is limited when its doing remote merges?

I didn't really do this change for this feature, I did for the
performance (see below).

> Also I thought there was a configuration variable that talks
> about "remote = ."  (didn't I merge that patch -- I do not
> remember offhand) and I wonder how that interacts with this
> change.

I must have missed that discussion on the list.  Not sure how as
I read everything.  Oh, its that grey stuff upstairs not recalling
history as well as Git does... ;-)

> How much performance gain are we talking about here?

It halves my 'git pull . foo' times on my Mac OS X PowerPC 64 system:

  Without: ~900 ms
  With:    ~440 ms

-- 
Shawn.