git weird pulling issue

git weird pulling issue

[Cyrill Gorcunov]

Hi git-list,

i've a weird problem with pulling remote tree. look i've linus's tree
as a base repo. then i've created x86 branch to which i pulled
ingo's x86 tree. So all further pulling is made over this branch.
And even having '--force' option at moment of pulling changes from
Ingo's tree i've got something like that:

---
cyrill@cvg linux-2.6-x86.git $ ./git-update.sh 
Updating "x86"
remote: Generating pack...
remote: Done counting 15 objects.
Result has 9 objects.
remote: Deltifying 9 objects...
remote: /9) done/9) done
remote: Total 9 (delta 7), reused 3 (delta 1)
Unpacking 9 objects...
 100% (9/9) done
Auto-merged include/asm-x86/msr.h
CONFLICT (content): Merge conflict in include/asm-x86/msr.h
Auto-merged include/linux/ptrace.h
Auto-merged kernel/ptrace.c
Automatic merge failed; fix conflicts and then commit the result.
---

I would really appreciate if someone helps me to resolve this
problem. If you need an additional info - just mail me.

Please Cc me 'case i'm not subscribed to the list.

Thanks in advance,

		- Cyrill -

Re: git weird pulling issue

[Junio C Hamano]

Cyrill Gorcunov <gorcunov@gmail.com> writes:

> Hi git-list,
>
> i've a weird problem with pulling remote tree. look i've linus's tree
> as a base repo. then i've created x86 branch to which i pulled
> ingo's x86 tree. So all further pulling is made over this branch.
> And even having '--force' option at moment of pulling changes from
> Ingo's tree i've got something like that:
>
> ---
> cyrill@cvg linux-2.6-x86.git $ ./git-update.sh 
> Updating "x86"
> remote: Generating pack...
> remote: Done counting 15 objects.
> Result has 9 objects.
> remote: Deltifying 9 objects...
> remote: /9) done/9) done
> remote: Total 9 (delta 7), reused 3 (delta 1)
> Unpacking 9 objects...
>  100% (9/9) done
> Auto-merged include/asm-x86/msr.h
> CONFLICT (content): Merge conflict in include/asm-x86/msr.h
> Auto-merged include/linux/ptrace.h
> Auto-merged kernel/ptrace.c
> Automatic merge failed; fix conflicts and then commit the result.

To your readers, "./git-update.sh" is a mystery script; nobody
knows what you are doing in there.

A handful points that might help anybody who wants to be
helpful.

 * The state your repository is in is a bit vague.  Let me try
   to rephrase your introductory part and see if I understood
   your history.

    * It started as a clone from Linus's
      git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

    * You say you created x86 branch (local) to which you pull
      Ingo's (I do not see any tree other than scheduler ones
      under git/mingo/), but it is unclear what this branch's
      history looks like.

      Was it done by

      	git checkout -b x86
	git pull git://.../mingo/x86/ master

      If so, (1) was the initial x86 before the first pull
      pristine Linus tree? (2) was the initial x86 pull
      fast-forward?

 * I am suspecting that git-update.sh is a wrapper around
   git-pull that does something like:

    git checkout x86 &&
    git pull git://.../mingo/x86/ master

   Do you have remote tracking information for Ingo's
   repository?  If so how does it look like?

   Do you have your own changes in your x86 branch?  Do they
   conflict with Ingo's change, IOW, is the conflict above just
   a normal thing to expect?  What makes you think there should
   not be any conflict?

There are a few reasons I can think of that can cause conflicts.

 - (obvious) you have your own changes that the tree you are
   pulling from have colliding changes;

 * the tree you are pulling from has rebased;

The --force is about allowing git-fetch to update the remote
tracking branches (if you use them) even when the tracking
information is not fast-forward.  Without --force, the fetch
would refuse to operate (and because git-pull is git-fetch
followed by git-merge, the entire operation would fail and the
merge won't even happen --- hence you would not even see
conflicts).  But the option does not change the fact that what
you are going to merge has conflicting changes with the changes
in your current branch.  It merely allows git-fetch to forcibly
update the remote tracking information and git-pull to proceed
with the merges.

I am suspecting that (1) you have remote tracking information
(perhaps set up with "git remote add"); and (2) Ingo's tree
rebased between the time your last pull and this time.  If you
do not have any local commits on the branch, resetting to the
remote tracking branch you use to track Ingo's progress is an
option.  If you do, then fetching and rebasing instead of
pulling may make further development easier.  But I cannot
really tell.

Re: git weird pulling issue

[Cyrill Gorcunov]

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