Re: How to update a cloned git repository

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

"Joachim Schmitz" <jojo@schmitz-digital.de> writes:

> Hi folks
>
> Probably a beginner's question...
>
> If I did a
>    git clone git://guthub.com/git/git.git
> and worked on some own branches of pu
>    git checkout pu;git checkout -p mybranch;

I guess you meant "git checkout -b mybranch" (not -p).

> hack;hack;...;git commit -a -s
>
> how to update my repository once the the one on github changed? A
> plain git pull or git fetch;git merge keeps failing on my with lots of
> conflicts, none of which relate to any of the changes I did (and hence
> wouldn't know how to resolve)

Short answer: don't work on pu. Work on master unless you have a good
reason not to.

Longer answer: the pu branch in git.git is often re-written, hence the
commit on which you started hacking once existed in git.git's pu, but it
probably no longer is.

You cloned this:

--A---B---C <-- origin/pu

Hacked to this

         origin/pu
          |
          v
--A---B---C---D---E <-- mybranch

and the next fetch resulted in something like this:

    B'---C'---D'---F <-- origin/pu
   /
--A---B---C---D---E <-- mybranch

while you could have expected that if origin/pu had just been
fast-forwarded with a new commit F:

            F <-- origin/pu
           /
--A---B---C---D---E <-- mybranch

As a result, "git merge" computes a common ancestor very far backward in
history. Instead of merging only your changes with new pu content, it
merges the old history of pu (plus your changes) with the new history of
pu, and you get spurious conflicts.

The solution is to rebase your changes (and only yours). My advice is to
rebase them on master, like this (replace 42 by the number of commits
you want to rebase in HEAD~42):

  git rebase HEAD~42 --onto origin/master

Once you did this, you can start using "git pull" (or "git pull
--rebase") as usual.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/