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

From: Junio C Hamano <junkio@cox.net>
Date: Dec 28, 2006, 09:35 UTC
Message-ID: <7vac18wego.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061228081701.GA18029@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

Show 12 quoted lines

>> 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?

Personally I do not mind much about it because I happen to understand what "git pull" is doing.

But I do mind having to spend time defending why we special case only the dot form, when people with twisted minds start complaining about inconsistencies among "git pull .git", "git pull ." and "git pull $(pwd)". And no, I do not want to introduce likes of "test `cd .git && pwd` == `cd $1 && pwd`" in the code to make them behave consistently.