Pull and fetch

Pull and fetch

[Paolo Ciarrocchi]

Hi all,
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:
paolo@paolo-desktop:~$ mkdir test
paolo@paolo-desktop:~$ cd test
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
remote: Generating pack...
[skip]
paolo@paolo-desktop:~/test$ git pull ../git master:testbranchpull
* refs/heads/testbranchpull: storing branch 'master' of ../git
  commit: e945f95

Now I have 3 branches:
paolo@paolo-desktop:~/test$ git branch
* master
  testbranch
  testbranchpull

All the branches have the same content, I expect to see differences between testbranch 
and testbranchpull. The first one is the end result of a fetch, the second one is
the end result of a pull.

git status always says:
  nothing to commit

Why?
What will happen if I repeat the same commands:
  git fetch ../git master:testbranch
  git pull ../git master:testbranchpull
after a change in the git master branch?

Thanks in advance?

Kind regards,
Paolo Ciarrocchi

Re: Pull and fetch

[Sean]

On Thu, 23 Nov 2006 20:39:50 +0100
Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:


> OK, make sense. So let's try with an experiment:
> paolo@paolo-desktop:~$ mkdir test
> paolo@paolo-desktop:~$ cd test
> paolo@paolo-desktop:~/test$ git-init-db 
> defaulting to local storage area

At this point your "master" branch will be empty.  You can see
this by doing a "git log"

> paolo@paolo-desktop:~/test$ git fetch ../git master:testbranch
> warning: no common commits
> remote: Generating pack...

If you do "git log" at this point you'll see your master branch
is still empty.  All you've done is fetched the remote branch
into your new repo as "testbranch"

> [skip]
> paolo@paolo-desktop:~/test$ git pull ../git master:testbranchpull
> * refs/heads/testbranchpull: storing branch 'master' of ../git
>   commit: e945f95

This command is different than fetch.  After fetching the remote
branch into your repo as "testbranchpull", it then merges it with
your currently checked out branch (master).  At this point if
you do a "git log"  you'll see your master is now populated with
the results of the merge (well in this case a fast forward).

So this nicely shows the difference of fetch and pull, and explains
how your "master" branch came to have something in it.

 
> Now I have 3 branches:
> paolo@paolo-desktop:~/test$ git branch
> * master
>   testbranch
>   testbranchpull
> 
> All the branches have the same content, I expect to see differences between testbranch 
> and testbranchpull. The first one is the end result of a fetch, the second one is
> the end result of a pull.

Yes, they will all have the same content.  As your local repo diverges
from the remote (as you make local commits) the difference between
fetch and pull will become more obvious and pronounced.

> git status always says:
>   nothing to commit
> 
> Why?

This just means you have no uncommitted local changes in your repo.  Edit
one of the file, and before committing the change, do "git status" again
and it will list the file as modified.

> What will happen if I repeat the same commands:
>   git fetch ../git master:testbranch
>   git pull ../git master:testbranchpull
> after a change in the git master branch?

Try it out :o)

Afterward, both testbranch and testbranchpull will be direct copies
of the other repo's master.  The fetch command will do nothing to
"master".  However, after updating your testbranchpull, the pull
command will merge (or fast forward) its contents into "master".

Cheers,

Re: Pull and fetch

[Paolo Ciarrocchi]

On 11/23/06, Sean <seanlkml@sympatico.ca> wrote:
> On Thu, 23 Nov 2006 21:45:32 +0100
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> wrote:

> > So it fetches into testbranchpull and merge its content with master.
> > Right?
>
> Exactly.  You'll hear people say, git-pull is simply a fetch + a merge.
> This is what they mean.

Fair enough.

> > Since master was empy I now have 3 identical branches if I'm getting
> > it correctly.
>
> Yes.
>
> > Not so sure I've got everything.
> >
> > If I do:
> > git checkout testbranch
> > edit file
> > git commit -a
> > git fetch ../git master:testbranch
>
> You are not allowed to fetch changes into a branch you have modified
> locally.   If you use the "-f" (force) option of fetch to force it,
> your local commits will be lost.

OK

> If you want to merge remote master changes into this testbranch
> after you've updated, you'd want:
>
> git pull ../git master
>
> (which fetches the remote master into a hidden temp branch, and
> then merges it with the locally checked out branch (testbranch))

Thanks, now I think I have a clear picture. I think it's worth to add
some more info to tutorial.txt about difference between fetch and
pull. I don't believe I'm the only confused user ;-)

> > Last command will merge my local change with the remote master but
> > will keep my local master unmodified, right?
>
> No.. Fetch never merges, only copies remote data into your repo.

I was confused by the "merge" terminology, if I fetch to an empty
branch the concept of copy is easy to be understood, but if I fetch to
a branch that contains data then it's somehow more difficult to think
about fetching without thinking of "merge the remote branch into
local".

But now I think I understood it ;-)


> But you're right, your local master would be unaffected.
>
> Cheers,
> Sean
>
> P.S.  Please keep the questions on the list.  That way if i get something
> wrong someone will correct it.  Someone else might be able to give
> you a better answer too.

Sure, sorry about that. It was not my intention, I just pressed the
wrong button :)

Regards,
-- 
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8

Re: Pull and fetch

[J. Bruce Fields]

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

[PATCH] Documentation: clarify tutorial pull/merge discussion

[J. Bruce Fields]

Attempt to clarify somewhat the difference between pull and merge,
and give a little more details on the pull syntax.

I'm still not happy with this section: the explanation of the origin
branch isn't great, but maybe that should be left alone pending the
use-separate-remotes change; and we need to explain how to set up a
public repository and push to it.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
 Documentation/tutorial.txt |   41 ++++++++++++++++++++++++++---------------
 1 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 1e4ddfb..35af81a 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -209,29 +209,28 @@ at /home/bob/myrepo.  She does this with
 
 ------------------------------------------------
 $ cd /home/alice/project
-$ git pull /home/bob/myrepo
+$ git pull /home/bob/myrepo master
 ------------------------------------------------
 
-This actually pulls changes from the branch in Bob's repository named
-"master".  Alice could request a different branch by adding the name
-of the branch to the end of the git pull command line.
+This merges the changes from Bob's "master" branch into Alice's
+current branch.  If Alice has made her own changes in the meantime,
+then she may need to manually fix any conflicts.  (Note that the
+"master" argument in the above command is actually unnecessary, as it
+is the default.)
 
-This merges Bob's changes into her repository; "git log" will
-now show the new commits.  If Alice has made her own changes in the
-meantime, then Bob's changes will be merged in, and she will need to
-manually fix any conflicts.
+The "pull" command thus performs two operations: it fetches changes
+from a remote branch, then merges them into the current branch.
 
-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:
+You can perform the first operation alone using the "git fetch"
+command.  For example, Alice could create a temporary branch just to
+track Bob's changes, without merging them with her own, using:
 
 -------------------------------------
 $ 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
+named bob-incoming.  Then
 
 -------------------------------------
 $ git log -p master..bob-incoming
@@ -240,8 +239,8 @@ $ git log -p master..bob-incoming
 shows a list of all the changes that Bob made since he branched from
 Alice's master branch.
 
-After examining those changes, and possibly fixing things, Alice can
-pull the changes into her master branch:
+After examining those changes, and possibly fixing things, Alice
+could pull the changes into her master branch:
 
 -------------------------------------
 $ git checkout master
@@ -251,6 +250,18 @@ $ git pull . bob-incoming
 The last command is a pull from the "bob-incoming" branch in Alice's
 own repository.
 
+Alice could also perform both steps at once with:
+
+-------------------------------------
+$ git pull /home/bob/myrepo master:bob-incoming
+-------------------------------------
+
+This is just like the "git pull /home/bob/myrepo master" that we saw
+before, except that it also stores the unmerged changes from bob's
+master branch in bob-incoming before merging them into Alice's
+current branch.  Note that git pull always merges into the current
+branch, regardless of what else is given on the commandline.
+
 Later, Bob can update his repo with Alice's latest changes using
 
 -------------------------------------
-- 
1.4.4.rc1.g83ee9

Re: [PATCH] Documentation: clarify tutorial pull/merge discussion

[Paolo Ciarrocchi]

On 11/26/06, J. Bruce Fields <bfields@fieldses.org> wrote:
> Attempt to clarify somewhat the difference between pull and merge,
> and give a little more details on the pull syntax.
>
> I'm still not happy with this section: the explanation of the origin
> branch isn't great, but maybe that should be left alone pending the
> use-separate-remotes change; and we need to explain how to set up a
> public repository and push to it.
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

A lot more clear in my opinion.

Acked-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>

Ciao,
-- 
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
http://www.linkedin.com/pub/0/132/9a3