Re: bad git pull
- From
- Carl Baldwin <cnb@fc.hp.com>
- Date
- Dec 16, 2005, 17:25 UTC
- Message-ID
- <20051216172535.GA25856@hpsvcnb.fc.hp.com>
- In-Reply-To
- <7vu0d9lxx9.fsf@assigned-by-dhcp.cox.net>
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:
Show 51 quoted lines
> 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -