[Junio C Hamano - Thu, Jan 03, 2008 at 11:59:50AM -0800] | Cyrill Gorcunov <gorcunov@xxxxxxxxx> writes: | | > so i hold only Linus's and Ingo's changes in repo not mine. | | Thanks. I think I know exactly what is going on. | | BTW, do not drop git@xxxxxxxxxxxxxxx from the CC: list without a | good reason, please. Otherwise I'd be spending my time *solely* | to help you, in which case I have to charge you for my time ;-) | oops ;) actually it wouldn't be a problem if (1) i've a well-paid work and (2) wouldn't live in Russia (from where is no simple way to pass a bit of charge to anyone from a regular men ;) So i prefer to keep git@ then ;) | If you find this message useful, you may forward it back to the | list along with your message I am responding to. | | Here is what is happening. | | (0) Ingo has this: | | A---B (== I) | / | ----o---o---o---L | | where L is the tip of Linus at some point, I is his changes | for x86. You pull and get the same thing. Your local x86 | tip points at commit B. | | (1) Then Linus advances and Ingo rebases. Updated Linus's tip | is at L' and Ingo has old patches rebased (A' and B') while | he added more changes (C and D). His tip is at I'. | | A---B (==I) A'--B'--C---D (==I') | / / | ----o---o---o---L---o---o---L' | | (2) You pull. What is involved is: | | * git-pull is just "git fetch" followed by "git merge", and | in your repository "git fetch" can be configured to use a | remote tracking branch to keep track of Ingo's progress | (but I suspect you don't). Your "git branch" output | shows your local branches, and "git branch -r" would show | these remote tracking branches. | | * The remote tracking is typically configured in | .git/config and would look like this: | | [remote "mingo"] | url = git://git.kernel.org/pub/... | fetch = refs/heads/*:refs/remotes/mingo/* | | Although I _suspect_ you do not have it (your $ipull | script pulls with explicit URL without using configured | information). | | The above (for normal people who have the tracking set up) | fetches the branch tip's from Ingo, and store them in | corresponding places in .git/refs/remotes/mingo/; his 'mm' | branch will be stored in .git/refs/remotes/mingo/mm. | | But remote.mingo.fetch configuration above does not start | with '+' (e.g. "+refs/heads/*:refs/remotes/mingo/*", which | means "do allow non-fast-forward"). For people with such | configuration, "git pull" from him will fail because | remotes/mingo/mm points at commit B before you initiated | the fetch and now it points at D which is _NOT_ a | descendant of B. | | His recommendation about --force applies _ONLY_ to override | this, and allow your remote tracking branch that used to | point at B to be replaced to point at D. I suspect it does | not even apply to you as I do not think you are using | remote tracking branch at all. | | In any case, once "git fetch" completes, "git merge" | happens. --force does not affect this step at all. | | What's merged? | | Your 'x86' branch is still at B and you try to merge D into | it. | | .-------------------* | / / | A---B A'--B'--C---D | / / | ----o---o---o---L---o---o---L' | | Because Ingo's tree was rebased, the resulting merge wants | to have both versions of A and B (the original and the | rebased). As corresponding patches (say A and A') would | want to touch same parts of the code, and Ingo may have | improved the latter while all of this has been happening | (i.e. A and A' may not be literal rebase but can do things | differently), it will inevitably conflict with each other. | | Even though the conflict resolution would be trivial (you would | basically want to pick what's from A' over A), this is not what | you would typically want to happen. When dealing with a | rebasing upstream, you often do not want to merge but instead | rebase yourself. | | So backing up a bit, here is how people would follow rebasing | upstream: | | (0) Ingo has this: | | A---B (== I) | / | ----o---o---o---L | | where L is the tip of Linus at some point, I is his changes | for x86. You pull and get the same thing. Your local x86 | tip points at commit B. | | (1) You develop on top of Ingo (although you hinted in your | description that you are strictly following, that is just a | degenerated case of this where (X,Y,Z) is empty in this | picture): | | X---Y---Z | / | A---B (== I) | / | ----o---o---o---L | | (2) Then Linus advances and Ingo rebases. Updated Linus's tip | is at L' and Ingo has old patches rebased (A' and B') while | he added more changes (C and D). His tip is at I'. | | A---B (==I) A'--B'--C---D (==I') | / / | ----o---o---o---L---o---o---L' | | (3) You do not pull but instead fetch from Ingo to get what | happened outside your tree. | | X---Y---Z | / | A---B (==I) A'--B'--C---D (==I') | / / | ----o---o---o---L---o---o---L' | | Note that your 'x86' is at Z and Ingo's tip is now at D. | | (4) You rebase on top of Ingo's updated tip. | | X'--Y'--Z' | / | A---B (==I) A'--B'--C---D (==I') | / / | ----o---o---o---L---o---o---L' | | | I was told that our user manual is very good these days covering | both workflows based on merges and workflows based on rebases. | You may want to check it and also git-rebase(1). | thanks Junio, and sorry for git@ list being dropped from CC. (didn't read this message in details) so i'll write you/git-list ASAP. Thanks a lot! - Cyrill - - 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
