{"thread":{"id":"11457","subject":"git weird pulling issue","startedAt":"2008-01-03T12:11:14Z","lastAt":"2008-01-03T20:08:37Z","messageCount":3,"participants":["Cyrill Gorcunov","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64384","messageId":"20080103121114.GE8046@cvg","threadId":"11457","inReplyTo":null,"subject":"git weird pulling issue","fromName":"Cyrill Gorcunov","fromEmail":"gorcunov@gmail.com","sentAt":"2008-01-03T12:11:14Z","receivedAt":"2008-01-03T12:11:14Z","isPatch":false,"sender":{"key":"gorcunov@gmail.com","avatar":"https://gravatar.com/avatar/b9d3eb8ea4efbd95564cedde5bf279ef8f36091cf61fac090c8cb75cc4ad6f8b?d=mp&s=160"},"body":"Hi git-list,\n\ni've a weird problem with pulling remote tree. look i've linus's tree\nas a base repo. then i've created x86 branch to which i pulled\ningo's x86 tree. So all further pulling is made over this branch.\nAnd even having '--force' option at moment of pulling changes from\nIngo's tree i've got something like that:\n\n---\ncyrill@cvg linux-2.6-x86.git $ ./git-update.sh \nUpdating \"x86\"\nremote: Generating pack...\nremote: Done counting 15 objects.\nResult has 9 objects.\nremote: Deltifying 9 objects...\nremote: /9) done/9) done\nremote: Total 9 (delta 7), reused 3 (delta 1)\nUnpacking 9 objects...\n 100% (9/9) done\nAuto-merged include/asm-x86/msr.h\nCONFLICT (content): Merge conflict in include/asm-x86/msr.h\nAuto-merged include/linux/ptrace.h\nAuto-merged kernel/ptrace.c\nAutomatic merge failed; fix conflicts and then commit the result.\n---\n\nI would really appreciate if someone helps me to resolve this\nproblem. If you need an additional info - just mail me.\n\nPlease Cc me 'case i'm not subscribed to the list.\n\nThanks in advance,\n\n\t\t- Cyrill -\n"},{"id":"64389","messageId":"7v4pdusspu.fsf@gitster.siamese.dyndns.org","threadId":"11457","inReplyTo":"20080103121114.GE8046@cvg","subject":"Re: git weird pulling issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-03T17:51:25Z","receivedAt":"2008-01-03T17:51:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Cyrill Gorcunov <gorcunov@gmail.com> writes:\n\n> Hi git-list,\n>\n> i've a weird problem with pulling remote tree. look i've linus's tree\n> as a base repo. then i've created x86 branch to which i pulled\n> ingo's x86 tree. So all further pulling is made over this branch.\n> And even having '--force' option at moment of pulling changes from\n> Ingo's tree i've got something like that:\n>\n> ---\n> cyrill@cvg linux-2.6-x86.git $ ./git-update.sh \n> Updating \"x86\"\n> remote: Generating pack...\n> remote: Done counting 15 objects.\n> Result has 9 objects.\n> remote: Deltifying 9 objects...\n> remote: /9) done/9) done\n> remote: Total 9 (delta 7), reused 3 (delta 1)\n> Unpacking 9 objects...\n>  100% (9/9) done\n> Auto-merged include/asm-x86/msr.h\n> CONFLICT (content): Merge conflict in include/asm-x86/msr.h\n> Auto-merged include/linux/ptrace.h\n> Auto-merged kernel/ptrace.c\n> Automatic merge failed; fix conflicts and then commit the result.\n\nTo your readers, \"./git-update.sh\" is a mystery script; nobody\nknows what you are doing in there.\n\nA handful points that might help anybody who wants to be\nhelpful.\n\n * The state your repository is in is a bit vague.  Let me try\n   to rephrase your introductory part and see if I understood\n   your history.\n\n    * It started as a clone from Linus's\n      git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\n    * You say you created x86 branch (local) to which you pull\n      Ingo's (I do not see any tree other than scheduler ones\n      under git/mingo/), but it is unclear what this branch's\n      history looks like.\n\n      Was it done by\n\n      \tgit checkout -b x86\n\tgit pull git://.../mingo/x86/ master\n\n      If so, (1) was the initial x86 before the first pull\n      pristine Linus tree? (2) was the initial x86 pull\n      fast-forward?\n\n * I am suspecting that git-update.sh is a wrapper around\n   git-pull that does something like:\n\n    git checkout x86 &&\n    git pull git://.../mingo/x86/ master\n\n   Do you have remote tracking information for Ingo's\n   repository?  If so how does it look like?\n\n   Do you have your own changes in your x86 branch?  Do they\n   conflict with Ingo's change, IOW, is the conflict above just\n   a normal thing to expect?  What makes you think there should\n   not be any conflict?\n\nThere are a few reasons I can think of that can cause conflicts.\n\n - (obvious) you have your own changes that the tree you are\n   pulling from have colliding changes;\n\n * the tree you are pulling from has rebased;\n\nThe --force is about allowing git-fetch to update the remote\ntracking branches (if you use them) even when the tracking\ninformation is not fast-forward.  Without --force, the fetch\nwould refuse to operate (and because git-pull is git-fetch\nfollowed by git-merge, the entire operation would fail and the\nmerge won't even happen --- hence you would not even see\nconflicts).  But the option does not change the fact that what\nyou are going to merge has conflicting changes with the changes\nin your current branch.  It merely allows git-fetch to forcibly\nupdate the remote tracking information and git-pull to proceed\nwith the merges.\n\nI am suspecting that (1) you have remote tracking information\n(perhaps set up with \"git remote add\"); and (2) Ingo's tree\nrebased between the time your last pull and this time.  If you\ndo not have any local commits on the branch, resetting to the\nremote tracking branch you use to track Ingo's progress is an\noption.  If you do, then fetching and rebasing instead of\npulling may make further development easier.  But I cannot\nreally tell.\n"},{"id":"64391","messageId":"20080103200837.GM8046@cvg","threadId":"11457","inReplyTo":"7vprwiptmx.fsf@gitster.siamese.dyndns.org","subject":"Re: git weird pulling issue","fromName":"Cyrill Gorcunov","fromEmail":"gorcunov@gmail.com","sentAt":"2008-01-03T20:08:37Z","receivedAt":"2008-01-03T20:08:37Z","isPatch":false,"sender":{"key":"gorcunov@gmail.com","avatar":"https://gravatar.com/avatar/b9d3eb8ea4efbd95564cedde5bf279ef8f36091cf61fac090c8cb75cc4ad6f8b?d=mp&s=160"},"body":"[Junio C Hamano - Thu, Jan 03, 2008 at 11:59:50AM -0800]\n| Cyrill Gorcunov <gorcunov@gmail.com> writes:\n| \n| > so i hold only Linus's and Ingo's changes in repo not mine.\n| \n| Thanks.  I think I know exactly what is going on.\n| \n| BTW, do not drop git@vger.kernel.org from the CC: list without a\n| good reason, please.  Otherwise I'd be spending my time *solely*\n| to help you, in which case I have to charge you for my time ;-)\n| \n\noops ;) actually it wouldn't be a problem if (1) i've a well-paid\nwork and (2) wouldn't live in Russia (from where is no simple way to\npass a bit of charge to anyone from a regular men ;) So i prefer\nto keep git@ then ;)\n\n| If you find this message useful, you may forward it back to the\n| list along with your message I am responding to.\n| \n| Here is what is happening.\n| \n|  (0) Ingo has this:\n| \n|                       A---B (== I)\n|                      /\n|     ----o---o---o---L\n| \n|      where L is the tip of Linus at some point, I is his changes\n|      for x86.  You pull and get the same thing.  Your local x86\n|      tip points at commit B.\n| \n|  (1) Then Linus advances and Ingo rebases.  Updated Linus's tip\n|      is at L' and Ingo has old patches rebased (A' and B') while\n|      he added more changes (C and D).  His tip is at I'.\n| \n|                       A---B (==I) A'--B'--C---D (==I')\n|                      /           /\n|     ----o---o---o---L---o---o---L'\n| \n|  (2) You pull.  What is involved is:\n| \n|      * git-pull is just \"git fetch\" followed by \"git merge\", and\n|        in your repository \"git fetch\" can be configured to use a\n|        remote tracking branch to keep track of Ingo's progress\n|        (but I suspect you don't).  Your \"git branch\" output\n|        shows your local branches, and \"git branch -r\" would show\n|        these remote tracking branches.\n| \n|      * The remote tracking is typically configured in\n|        .git/config and would look like this:\n| \n|         [remote \"mingo\"]\n|         url = git://git.kernel.org/pub/...\n|         fetch = refs/heads/*:refs/remotes/mingo/*\n| \n|         Although I _suspect_ you do not have it (your $ipull\n|         script pulls with explicit URL without using configured\n|         information).\n| \n|      The above (for normal people who have the tracking set up)\n|      fetches the branch tip's from Ingo, and store them in\n|      corresponding places in .git/refs/remotes/mingo/;  his 'mm'\n|      branch will be stored in .git/refs/remotes/mingo/mm.\n| \n|      But remote.mingo.fetch configuration above does not start\n|      with '+' (e.g. \"+refs/heads/*:refs/remotes/mingo/*\", which\n|      means \"do allow non-fast-forward\").  For people with such\n|      configuration, \"git pull\" from him will fail because\n|      remotes/mingo/mm points at commit B before you initiated\n|      the fetch and now it points at D which is _NOT_ a\n|      descendant of B.\n| \n|      His recommendation about --force applies _ONLY_ to override\n|      this, and allow your remote tracking branch that used to\n|      point at B to be replaced to point at D.  I suspect it does\n|      not even apply to you as I do not think you are using\n|      remote tracking branch at all.\n| \n|      In any case, once \"git fetch\" completes, \"git merge\"\n|      happens.  --force does not affect this step at all.\n| \n|      What's merged?\n| \n|      Your 'x86' branch is still at B and you try to merge D into\n|      it.\n| \n|                             .-------------------*\n|                            /                   / \n|                       A---B       A'--B'--C---D\n|                      /           /\n|     ----o---o---o---L---o---o---L'\n| \n|      Because Ingo's tree was rebased, the resulting merge wants\n|      to have both versions of A and B (the original and the\n|      rebased).  As corresponding patches (say A and A') would\n|      want to touch same parts of the code, and Ingo may have\n|      improved the latter while all of this has been happening\n|      (i.e. A and A' may not be literal rebase but can do things\n|      differently), it will inevitably conflict with each other.\n| \n| Even though the conflict resolution would be trivial (you would\n| basically want to pick what's from A' over A), this is not what\n| you would typically want to happen.  When dealing with a\n| rebasing upstream, you often do not want to merge but instead\n| rebase yourself.\n| \n| So backing up a bit, here is how people would follow rebasing\n| upstream:\n| \n|  (0) Ingo has this:\n| \n|                       A---B (== I)\n|                      /\n|     ----o---o---o---L\n| \n|      where L is the tip of Linus at some point, I is his changes\n|      for x86.  You pull and get the same thing.  Your local x86\n|      tip points at commit B.\n| \n|  (1) You develop on top of Ingo (although you hinted in your\n|      description that you are strictly following, that is just a\n|      degenerated case of this where (X,Y,Z) is empty in this\n|      picture):\n| \n|                             X---Y---Z\n|                            /\n|                       A---B (== I)\n|                      /\n|     ----o---o---o---L\n| \n|  (2) Then Linus advances and Ingo rebases.  Updated Linus's tip\n|      is at L' and Ingo has old patches rebased (A' and B') while\n|      he added more changes (C and D).  His tip is at I'.\n| \n|                       A---B (==I) A'--B'--C---D (==I')\n|                      /           /\n|     ----o---o---o---L---o---o---L'\n| \n|  (3) You do not pull but instead fetch from Ingo to get what\n|      happened outside your tree.\n| \n|                             X---Y---Z\n|                            /\n|                       A---B (==I) A'--B'--C---D (==I')\n|                      /           /\n|     ----o---o---o---L---o---o---L'\n| \n|     Note that your 'x86' is at Z and Ingo's tip is now at D.\n| \n|  (4) You rebase on top of Ingo's updated tip.\n| \n|                                                 X'--Y'--Z'\n|                                                /\n|                       A---B (==I) A'--B'--C---D (==I')\n|                      /           /\n|     ----o---o---o---L---o---o---L'\n| \n| \n| I was told that our user manual is very good these days covering\n| both workflows based on merges and workflows based on rebases.\n| You may want to check it and also git-rebase(1).\n|\n\nthanks Junio, and sorry for git@ list being dropped from CC.\n(didn't read this message in details) so i'll write you/git-list ASAP.\nThanks a lot!\n\n\t\t- Cyrill -\n"}]}