[ Re-adding git@vger in Cc, I guess it was meant to be so ] "Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> writes: >> 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. > > These are not available from git hub. Or are they? How? I think they exist in some of the repos junio pushes to, but I don't remember how/which one. Anyway, you can easily get it from the commit that merges the branch (it's the-merge-commit^1). >> > 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. > > OK, I'll try that next time then. Like this? > git fetch;git rebase HEAD~42 --onto origin/pu That should work, yes. In general, when you have a somehow complex workflow, I recommand fetch+(merge|rebase) over pull. It gives you more flexibility, and the opportunity to check what you fetched before starting the merge. >> > 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 ;-). > > Indeed ;-) > > > -- 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