> From: Matthieu Moy [mailto:Matthieu.Moy@xxxxxxxxxxxxxxx] > Sent: Tuesday, September 11, 2012 1:06 PM > To: Joachim Schmitz > Cc: git@xxxxxxxxxxxxxxx > Subject: Re: How to update a cloned git repository > > "Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> 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). Yes, of course... > > 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. There are some changes in pu, that I need as the basis, namely my setitimer patch and my 2nd mkdir patch, which haven't yet made it into the master branch (and in the setitimer case not out of pu) > 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 For pu this would be similar? > Once you did this, you can start using "git pull" (or "git pull > --rebase") as usual. Like this? git pull --rebase HEAD~42 So far I create patches, wiped out the entire repository, cloned, forked and applied the changes, pretty painful. -- 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