Re: bad git pull

[Carl Baldwin <cnb@fc.hp.com>]

Hello,

Here are my two cents.  I'll try my best to make a case for those poor
souls who get into this sort of mess.

Whenever I give a colleage an introduction to git I emphatically
recommend that they start with using git fetch and git merge
independantly of each other and stay away for git pull at least until
they know what they're doing.  This is because I have found that people
are really surprised at what happens when they type git pull until it
really sinks in that 'pull = fetch + merge to current branch, whatever
that may be'.

The difference between the words fetch and pull is much more subtle than
the difference between remove and list which are the basis for the
commands rm and ls.  I see nothing in the English dictionary to suggest
that pull means fetch + merge.  This is a gitism.  Even after reading
documentation clearly and even using git for a while the difference
really takes some time to sink in.

I think a great degree of understanding should be shown toward those who
dig themselves into this kind of thing.  I also recommend that some
extra care should be taken in the tutorials and documentation to warn
about this difference up front and possibly suggest avoiding the use of
pull for those new to git.

Carl

PS The issue was exacerbated when cogito and git were inconsistent on
their respective usages of pull and fetch.  I think this has gone away,
hasn't it?  I haven't used cogito in some time so I really don't know.

On Thu, Dec 15, 2005 at 03:53:38PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> 
> > Don Zickus <dzickus@gmail.com> writes:
> >
> >> I notice if I create a branch (and switch to it) in the linux kernel
> >> off of say version 2.6.14, then later do a git pull, things get ugly. 
> >> It seems like all the upstream changes are being merged into the
> >> 2.6.14 branch (instead of the latest kernel tag).
> >>
> >> Is this a user error because the tool is still fragile?
> >
> > I do not understand the question.
> >
> > The user wanted all the good developments from the mainline into
> > the fork he created starting at 2.6.14, and the tool did what
> > was asked.  Why would you want to forbid that from happening,
> > and what did you want to happen instead?
> 
> Actually I think I do understand the question.  You have a clone
> of linux-2.6 repository, and your "origin" branch tracks the
> bleeding edge from Linus.  You also have "myhack" branch that
> was forked off from 2.6.14, and wanted to see what new things
> Linus has by updating "origin", and perhaps merge those changes
> into your "master" which keeps track of your hacks based on
> Linus tip, but unfortunately you were on "myhack" branch.
> 
> Ouch.
> 
> So what you wanted to do was probably:
> 
> 	$ git fetch ;# this updates "origin" to Linus tip
> 
> instead of
> 
> 	$ git pull ;# this updates "origin" to Linus tip *and*
>                     # merges that into the current branch
> 
> As you may probably know, you can recover by
> 
> 	$ git reset --hard
> 
> While I am sympathetic, this "Oops, I said pull when I meant
> fetch" sounds remotely similar to "oops, I said 'rm -r' when I
> meant to say 'ls -r'".  Is it that the tool is too fragile?
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -