"Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> writes: >> From: Matthieu Moy [mailto:Matthieu.Moy@xxxxxxxxxxxxxxx] >> >> 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) Then, work on the tip of the topic branch you depend on instead of pu. These are more stable, as they will be rewritten only if this particular topic branch changes. >> git rebase HEAD~42 --onto origin/master > > For pu this would be similar? Yes. If you insist in working on top of pu, you can rebase --onto origin/pu. > Like this? > git pull --rebase HEAD~42 That would be "git fetch" and then "git rebase", as I don't think "git pull --rebase" would allow you to specify the starting point for rebase. > So far I create patches, wiped out the entire repository, cloned, > forked and applied the changes, pretty painful. This is conceptually similar to what "git rebase" does, but it does it in a slightly more efficient way ;-). -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html