Junio C Hamano <junkio@xxxxxxx> wrote:
> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html