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

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Jun 11, 2008, 21:01 UTC
Message-ID: <kpNEshc02wSu18FDnzOIvMAjQu_lmbk4tK_T_9HGh38@cipher.nrlssc.navy.mil>
In-Reply-To: <alpine.LNX.1.00.0806111513380.19665@iabervon.org>

Daniel Barkalow wrote:

Show 25 quoted lines

> On Wed, 11 Jun 2008, Brandon Casey wrote:
> 
>> Daniel Barkalow wrote:
>>> 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?
> 
> "git pull . <branch>" does "git fetch . <branch>" and then merges it. Of 
> course, "git fetch . <branch>" does nothing at all, and it's weird as a 
> user interface to have the only (simple) way of selecting something to 
> merge be to fetch it as if from a remote repository, but from the local 
> repository. After all, no other purely local operation requires you to 
> first fetch the thing you're interesting in from yourself.

I don't agree with this paragraph. I think it _would_ be weird if you had to type 'git fetch' and then 'git merge' (or git pull) when operating on a local repository, but that is not necessary. It is only necessary to type 'git pull'. There is symmetry between operating on a remote repository and operating on a local repository. The user does not need to know that a noop fetch is first performed, or whether the pull command detects that it is operating on a local repository and just skips the fetch, any more than the user is required to know the exact sequence of events that allows an ssh session to succeed.

Show 14 quoted lines

>> 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.
> 
> I think everybody uses "git merge" instead of "git pull ." these days. 
> It's shorter and less fiddly to type, and doesn't polute your bash reverse 
> search for "git pull<tab>" with local things. And, if you've got a bunch 
> of local branches, which is not uncommon and very much native to git, the 
> intuitive thing is to merge them with "git merge" instead of treating them 
> as if they weren't local.

Not sure about this one either. I think git-merge is intuitive to those who are familiar with the operation of git-pull, specifically those that understand how to use git-fetch and that git-pull does a fetch and then a merge. For those new to git, I think git-fetch takes a little while to get a handle on.

git-pull allows treating all branches as equal for merging purposes. A user does not have to differentiate between a local and a remote branch by using different commands. So I did not see it as 'treating [a local branch] as if they weren't local', but instead as a single command to merge branches regardless of whether they are local or remote.

Suggesting git-merge is what requires the user to make a distinction between local and remote branches.

Show 5 quoted lines

> It's also now pretty common to want to do "git fetch <remote>", inspect 
> it, decide whether this is something you want to merge (and depend on), 
> and do "git merge <tracking>" to include it in your branch if you want it. 
> (And being able to fetch stuff from a remote location, and later do a 
> merge without any non-local information is also very git-style.)

Yes, I agree that it is common to fetch and inspect before merging. The 'git merge <tracking>' could have been 'git pull . <tracking>', which only requires typing one additional character. The user _must_ know how to use git-pull, and the concept of '.' as a placeholder for the local repository takes only a moment to digest. git-merge is an additional command that the user must know when to use and when not to use. Well maybe that exaggerates the point a little, git-merge is not that complicated, but it is an additional command to learn with little benefit that I see.

To summarize my point, I think the recommended advertised merge command could be one single command 'git-pull' and that it should be used in the documentation in preference to 'git-merge'. It seems to me that this simplifies the user interface and requires the user to master fewer commands before becoming productive.

Also, I thought this was already the status-quo and so I have been surprised by the increasing suggestions to use git-merge on the mailing list. I saw it as something similar to suggestions I've seen to use git-reflog (not porcelain) rather than 'git-log -g' (porcelain).

-brandon