"Joachim Schmitz" <j...@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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
