On Thu, Nov 23, 2006 at 08:39:50PM +0100, Paolo Ciarrocchi wrote: > I'm still reading git tutorial.txt and I'm again confused. > > A more cautious Alice might wish to examine Bob's changes before > pulling them. She can do this by creating a temporary branch just > for the purpose of studying Bob's changes: > > ------------------------------------- > $ git fetch /home/bob/myrepo master:bob-incoming > ------------------------------------- > > which fetches the changes from Bob's master branch into a new branch > named bob-incoming. (Unlike git pull, git fetch just fetches a copy > of Bob's line of development without doing any merging). Then > > ------------------------------------- > $ git log -p master..bob-incoming > ------------------------------------- > > shows a list of all the changes that Bob made since he branched from > Alice's master branch. > > OK, make sense. So let's try with an experiment: Your experiment is quite different from what's described above; you're fetching into an *empty* repository, instead of fetching a branch that diverged from the work in the repository: > paolo@paolo-desktop:~/test$ git-init-db > defaulting to local storage area > paolo@paolo-desktop:~/test$ git fetch ../git master:testbranch > warning: no common commits and you're running "pull" with a syntax that has so far only been introduced for "fetch": > paolo@paolo-desktop:~/test$ git pull ../git master:testbranchpull By its nature a tutorial tends to follow a narrow path, and not offer much explanation of what will happen if you stray from that path. That said, I agree that the treatment of pull and fetch here could be better. And the ref:ref syntax for pull may be an obvious enough thing to try that we should document it here. Just as long as we keep it short.... --b. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html