Re: git weird pulling issue

[Cyrill Gorcunov <gorcunov@gmail.com>]

[Junio C Hamano - Thu, Jan 03, 2008 at 11:59:50AM -0800]
| Cyrill Gorcunov <gorcunov@gmail.com> 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@vger.kernel.org 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 -