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

From: Mikael Magnusson <mikachu@gmail.com>
Date: Jun 11, 2008, 21:49 UTC
Message-ID: <237967ef0806111449i7d23976dxa3290eece06b5876@mail.gmail.com>
In-Reply-To: <kpNEshc02wSu18FDnzOIvMAjQu_lmbk4tK_T_9HGh38@cipher.nrlssc.navy.mil>

2008/6/11 Brandon Casey <casey@nrlssc.navy.mil>:

Show 36 quoted lines

> Daniel Barkalow wrote:
>> 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.

> The user _must_ know how to use git-pull

I've used git for a couple of months, and I've never used git-pull, only fetch and merge. To me it doesn't make any sense that you would want to merge changes without looking at them first. It also seems very strange to me to treat not-yet-fetched branches on a remote the same as a local branch. I don't really have any useful input other than that you shouldn't assume what other people find intuitive, because you are usually wrong :).

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

For me, git-pull is that additional command, and using git-pull . <branch> to merge feels really really strange. Why would I pull something I already have?

> I saw it as something similar to suggestions I've seen to use git-reflog
> (not porcelain) rather than 'git-log -g' (porcelain).

The output of git-reflog is easier to read when you know what you're looking for, the actual commit message and author info that log outputs is usually superfluous.

-- 
Mikael Magnusson