Re: "git pull . <branch>" versus "git merge <branch>"

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Jun 11, 2008, 18:32 UTC
Message-ID: <XZoDb2arIiMts-bX6jjK15wC9cOn5lPGgCOQYbY9YIyNm_nfcDf5gQ@cipher.nrlssc.navy.mil>
In-Reply-To: <alpine.LNX.1.00.0806111340570.19665@iabervon.org>

Daniel Barkalow wrote:

Show 12 quoted lines

> On Wed, 11 Jun 2008, Rene Herman wrote:
> 
>> Good day.
>>
>> The manpages seem to be making somewhat of a point of mentioning "git pull .
>> <branch>" as the way to merge a local branch into the current one but a simple
>> "git merge <branch>" seems to work well. Is there a difference?
> 
> Those manpage sections predate the existance of "git merge <branch>". If 
> you're not planning to use git before November 2006, there's no reason to 
> use the "git pull ." form. They should probably be replaced with more 
> helpful examples at this point.

Was there some past discussion of the ui merits of a separate 'merge' command for dealing with local merges and a 'pull' command for remote merges? I understand merge is the backend. The question has to do with the high-level user interface: one command or two? Why wasn't git-pull enough?

I ask because elsewhere in this thread Miklos suggests that git-merge should be preferred over git-pull when dealing with a local repostory and you suggest here that the documentation should be updated to use the 'git merge' method instead of 'git pull'. I had the impression that git-merge was only used by those who had not yet gotten their mind around the pull methodology. So it was more of an 'ease the transition from other SCMs' rather than the recommended way of doing things.

-brandon