{"thread":{"id":"43455","subject":"Re: Pull and fetch","startedAt":"2006-11-23T19:39:50Z","lastAt":"2006-11-26T18:05:00Z","messageCount":6,"participants":["Paolo Ciarrocchi","J. Bruce Fields","Sean"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297550","messageId":"20061123203950.5d47421f@paolo-desktop","threadId":"43455","inReplyTo":null,"subject":"Pull and fetch","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2006-11-23T19:39:50Z","receivedAt":"2006-11-23T19:39:50Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"Hi all,\nI'm still reading git tutorial.txt and I'm again confused.\n\n A more cautious Alice might wish to examine Bob's changes before\n pulling them. She can do this by creating a temporary branch just\n for the purpose of studying Bob's changes:\n\n -------------------------------------\n $ git fetch /home/bob/myrepo master:bob-incoming\n -------------------------------------\n\n which fetches the changes from Bob's master branch into a new branch\n named bob-incoming. (Unlike git pull, git fetch just fetches a copy\n of Bob's line of development without doing any merging). Then\n\n -------------------------------------\n $ git log -p master..bob-incoming\n -------------------------------------\n\n shows a list of all the changes that Bob made since he branched from\n Alice's master branch.\n\nOK, make sense. So let's try with an experiment:\npaolo@paolo-desktop:~$ mkdir test\npaolo@paolo-desktop:~$ cd test\npaolo@paolo-desktop:~/test$ git-init-db \ndefaulting to local storage area\npaolo@paolo-desktop:~/test$ git fetch ../git master:testbranch\nwarning: no common commits\nremote: Generating pack...\n[skip]\npaolo@paolo-desktop:~/test$ git pull ../git master:testbranchpull\n* refs/heads/testbranchpull: storing branch 'master' of ../git\n commit: e945f95\n\nNow I have 3 branches:\npaolo@paolo-desktop:~/test$ git branch\n* master\n testbranch\n testbranchpull\n\nAll the branches have the same content, I expect to see differences between testbranch \nand testbranchpull. The first one is the end result of a fetch, the second one is\nthe end result of a pull.\n\ngit status always says:\n nothing to commit\n\nWhy?\nWhat will happen if I repeat the same commands:\n git fetch ../git master:testbranch\n git pull ../git master:testbranchpull\nafter a change in the git master branch?\n\nThanks in advance?\n\nKind regards,\nPaolo Ciarrocchi\n"},{"id":"297491","messageId":"BAYC1-PASMTP11EB389CA59410315B2F8AAEE20@CEZ.ICE","threadId":"43455","inReplyTo":"20061123203950.5d47421f@paolo-desktop","subject":"Re: Pull and fetch","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-23T20:36:24Z","receivedAt":"2006-11-23T20:36:24Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 23 Nov 2006 20:39:50 +0100\nPaolo Ciarrocchi wrote:\n\n\n> OK, make sense. So let's try with an experiment:\n> paolo@paolo-desktop:~$ mkdir test\n> paolo@paolo-desktop:~$ cd test\n> paolo@paolo-desktop:~/test$ git-init-db \n> defaulting to local storage area\n\nAt this point your \"master\" branch will be empty. You can see\nthis by doing a \"git log\"\n\n> paolo@paolo-desktop:~/test$ git fetch ../git master:testbranch\n> warning: no common commits\n> remote: Generating pack...\n\nIf you do \"git log\" at this point you'll see your master branch\nis still empty. All you've done is fetched the remote branch\ninto your new repo as \"testbranch\"\n\n> [skip]\n> paolo@paolo-desktop:~/test$ git pull ../git master:testbranchpull\n> * refs/heads/testbranchpull: storing branch 'master' of ../git\n> commit: e945f95\n\nThis command is different than fetch. After fetching the remote\nbranch into your repo as \"testbranchpull\", it then merges it with\nyour currently checked out branch (master). At this point if\nyou do a \"git log\" you'll see your master is now populated with\nthe results of the merge (well in this case a fast forward).\n\nSo this nicely shows the difference of fetch and pull, and explains\nhow your \"master\" branch came to have something in it.\n\n \n> Now I have 3 branches:\n> paolo@paolo-desktop:~/test$ git branch\n> * master\n> testbranch\n> testbranchpull\n> \n> All the branches have the same content, I expect to see differences between testbranch \n> and testbranchpull. The first one is the end result of a fetch, the second one is\n> the end result of a pull.\n\nYes, they will all have the same content. As your local repo diverges\nfrom the remote (as you make local commits) the difference between\nfetch and pull will become more obvious and pronounced.\n\n> git status always says:\n> nothing to commit\n> \n> Why?\n\nThis just means you have no uncommitted local changes in your repo. Edit\none of the file, and before committing the change, do \"git status\" again\nand it will list the file as modified.\n\n> What will happen if I repeat the same commands:\n> git fetch ../git master:testbranch\n> git pull ../git master:testbranchpull\n> after a change in the git master branch?\n\nTry it out :o)\n\nAfterward, both testbranch and testbranchpull will be direct copies\nof the other repo's master. The fetch command will do nothing to\n\"master\". However, after updating your testbranchpull, the pull\ncommand will merge (or fast forward) its contents into \"master\".\n\nCheers,\n"},{"id":"294867","messageId":"4d8e3fd30611240130m2d04efe8qcc8bb5d61f8c7386@mail.gmail.com","threadId":"43455","inReplyTo":"BAYC1-PASMTP11A008C336418A659F0E75AEE20@CEZ.ICE","subject":"Re: Pull and fetch","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2006-11-24T09:30:33Z","receivedAt":"2006-11-24T09:30:33Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 11/23/06, Sean wrote:\n> On Thu, 23 Nov 2006 21:45:32 +0100\n> \"Paolo Ciarrocchi\" wrote:\n\n> > So it fetches into testbranchpull and merge its content with master.\n> > Right?\n>\n> Exactly. You'll hear people say, git-pull is simply a fetch + a merge.\n> This is what they mean.\n\nFair enough.\n\n> > Since master was empy I now have 3 identical branches if I'm getting\n> > it correctly.\n>\n> Yes.\n>\n> > Not so sure I've got everything.\n> >\n> > If I do:\n> > git checkout testbranch\n> > edit file\n> > git commit -a\n> > git fetch ../git master:testbranch\n>\n> You are not allowed to fetch changes into a branch you have modified\n> locally. If you use the \"-f\" (force) option of fetch to force it,\n> your local commits will be lost.\n\nOK\n\n> If you want to merge remote master changes into this testbranch\n> after you've updated, you'd want:\n>\n> git pull ../git master\n>\n> (which fetches the remote master into a hidden temp branch, and\n> then merges it with the locally checked out branch (testbranch))\n\nThanks, now I think I have a clear picture. I think it's worth to add\nsome more info to tutorial.txt about difference between fetch and\npull. I don't believe I'm the only confused user ;-)\n\n> > Last command will merge my local change with the remote master but\n> > will keep my local master unmodified, right?\n>\n> No.. Fetch never merges, only copies remote data into your repo.\n\nI was confused by the \"merge\" terminology, if I fetch to an empty\nbranch the concept of copy is easy to be understood, but if I fetch to\na branch that contains data then it's somehow more difficult to think\nabout fetching without thinking of \"merge the remote branch into\nlocal\".\n\nBut now I think I understood it ;-)\n\n\n> But you're right, your local master would be unaffected.\n>\n> Cheers,\n> Sean\n>\n> P.S. Please keep the questions on the list. That way if i get something\n> wrong someone will correct it. Someone else might be able to give\n> you a better answer too.\n\nSure, sorry about that. It was not my intention, I just pressed the\nwrong button :)\n\nRegards,\n-- \nPaolo\nhttp://docs.google.com/View?docid=dhbdhs7d_4hsxqc8\n"},{"id":"296902","messageId":"20061124161144.GA19708@fieldses.org","threadId":"43455","inReplyTo":"20061123203950.5d47421f@paolo-desktop","subject":"Re: Pull and fetch","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-11-24T16:11:44Z","receivedAt":"2006-11-24T16:11:44Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Nov 23, 2006 at 08:39:50PM +0100, Paolo Ciarrocchi wrote:\n> I'm still reading git tutorial.txt and I'm again confused.\n> \n> A more cautious Alice might wish to examine Bob's changes before\n> pulling them. She can do this by creating a temporary branch just\n> for the purpose of studying Bob's changes:\n> \n> -------------------------------------\n> $ git fetch /home/bob/myrepo master:bob-incoming\n> -------------------------------------\n> \n> which fetches the changes from Bob's master branch into a new branch\n> named bob-incoming. (Unlike git pull, git fetch just fetches a copy\n> of Bob's line of development without doing any merging). Then\n> \n> -------------------------------------\n> $ git log -p master..bob-incoming\n> -------------------------------------\n> \n> shows a list of all the changes that Bob made since he branched from\n> Alice's master branch.\n> \n> OK, make sense. So let's try with an experiment:\n\nYour experiment is quite different from what's described above; you're\nfetching into an *empty* repository, instead of fetching a branch that\ndiverged from the work in the repository:\n\n> paolo@paolo-desktop:~/test$ git-init-db \n> defaulting to local storage area\n> paolo@paolo-desktop:~/test$ git fetch ../git master:testbranch\n> warning: no common commits\n\nand you're running \"pull\" with a syntax that has so far only been\nintroduced for \"fetch\":\n\n> paolo@paolo-desktop:~/test$ git pull ../git master:testbranchpull\n\nBy its nature a tutorial tends to follow a narrow path, and not offer\nmuch explanation of what will happen if you stray from that path.\n\nThat said, I agree that the treatment of pull and fetch here could be\nbetter. And the ref:ref syntax for pull may be an obvious enough thing\nto try that we should document it here. Just as long as we keep it\nshort....\n\n"},{"id":"297124","messageId":"20061126034502.GA3782@fieldses.org","threadId":"43455","inReplyTo":"20061124161144.GA19708@fieldses.org","subject":"[PATCH] Documentation: clarify tutorial pull/merge discussion","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-11-26T03:45:02Z","receivedAt":"2006-11-26T03:45:02Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"Attempt to clarify somewhat the difference between pull and merge,\nand give a little more details on the pull syntax.\n\nI'm still not happy with this section: the explanation of the origin\nbranch isn't great, but maybe that should be left alone pending the\nuse-separate-remotes change; and we need to explain how to set up a\npublic repository and push to it.\n\nSigned-off-by: J. Bruce Fields \n---\n Documentation/tutorial.txt | 41 ++++++++++++++++++++++++++---------------\n 1 files changed, 26 insertions(+), 15 deletions(-)\n\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\nindex 1e4ddfb..35af81a 100644\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -209,29 +209,28 @@ at /home/bob/myrepo. She does this with\n \n ------------------------------------------------\n $ cd /home/alice/project\n-$ git pull /home/bob/myrepo\n+$ git pull /home/bob/myrepo master\n ------------------------------------------------\n \n-This actually pulls changes from the branch in Bob's repository named\n-\"master\". Alice could request a different branch by adding the name\n-of the branch to the end of the git pull command line.\n+This merges the changes from Bob's \"master\" branch into Alice's\n+current branch. If Alice has made her own changes in the meantime,\n+then she may need to manually fix any conflicts. (Note that the\n+\"master\" argument in the above command is actually unnecessary, as it\n+is the default.)\n \n-This merges Bob's changes into her repository; \"git log\" will\n-now show the new commits. If Alice has made her own changes in the\n-meantime, then Bob's changes will be merged in, and she will need to\n-manually fix any conflicts.\n+The \"pull\" command thus performs two operations: it fetches changes\n+from a remote branch, then merges them into the current branch.\n \n-A more cautious Alice might wish to examine Bob's changes before\n-pulling them. She can do this by creating a temporary branch just\n-for the purpose of studying Bob's changes:\n+You can perform the first operation alone using the \"git fetch\"\n+command. For example, Alice could create a temporary branch just to\n+track Bob's changes, without merging them with her own, using:\n \n -------------------------------------\n $ git fetch /home/bob/myrepo master:bob-incoming\n -------------------------------------\n \n which fetches the changes from Bob's master branch into a new branch\n-named bob-incoming. (Unlike git pull, git fetch just fetches a copy\n-of Bob's line of development without doing any merging). Then\n+named bob-incoming. Then\n \n -------------------------------------\n $ git log -p master..bob-incoming\n@@ -240,8 +239,8 @@ $ git log -p master..bob-incoming\n shows a list of all the changes that Bob made since he branched from\n Alice's master branch.\n \n-After examining those changes, and possibly fixing things, Alice can\n-pull the changes into her master branch:\n+After examining those changes, and possibly fixing things, Alice\n+could pull the changes into her master branch:\n \n -------------------------------------\n $ git checkout master\n@@ -251,6 +250,18 @@ $ git pull . bob-incoming\n The last command is a pull from the \"bob-incoming\" branch in Alice's\n own repository.\n \n+Alice could also perform both steps at once with:\n+\n+-------------------------------------\n+$ git pull /home/bob/myrepo master:bob-incoming\n+-------------------------------------\n+\n+This is just like the \"git pull /home/bob/myrepo master\" that we saw\n+before, except that it also stores the unmerged changes from bob's\n+master branch in bob-incoming before merging them into Alice's\n+current branch. Note that git pull always merges into the current\n+branch, regardless of what else is given on the commandline.\n+\n Later, Bob can update his repo with Alice's latest changes using\n \n -------------------------------------\n-- \n1.4.4.rc1.g83ee9\n"},{"id":"297895","messageId":"4d8e3fd30611261005w20279017la17a7a6639481b3e@mail.gmail.com","threadId":"43455","inReplyTo":"20061126034502.GA3782@fieldses.org","subject":"Re: [PATCH] Documentation: clarify tutorial pull/merge discussion","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2006-11-26T18:05:00Z","receivedAt":"2006-11-26T18:05:00Z","isPatch":true,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 11/26/06, J. Bruce Fields wrote:\n> Attempt to clarify somewhat the difference between pull and merge,\n> and give a little more details on the pull syntax.\n>\n> I'm still not happy with this section: the explanation of the origin\n> branch isn't great, but maybe that should be left alone pending the\n> use-separate-remotes change; and we need to explain how to set up a\n> public repository and push to it.\n>\n> Signed-off-by: J. Bruce Fields \n\nA lot more clear in my opinion.\n\nAcked-by: Paolo Ciarrocchi \n\nCiao,\n-- \nPaolo\nhttp://docs.google.com/View?docid=dhbdhs7d_4hsxqc8\nhttp://www.linkedin.com/pub/0/132/9a3\n\n"}]}