Re: Pull and fetch
- From
- J. Bruce Fields <bfields@fieldses.org>
- Date
- Nov 24, 2006, 16:11 UTC
- Message-ID
- <20061124161144.GA19708@fieldses.org>
- In-Reply-To
- <20061123203950.5d47421f@paolo-desktop>
On Thu, Nov 23, 2006 at 08:39:50PM +0100, Paolo Ciarrocchi wrote:
Show 22 quoted lines
> 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....