"Joachim Schmitz" <j...@schmitz-digital.de> writes:
>> From: Matthieu Moy [mailto:matthieu....@grenoble-inp.fr]
>> 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
> 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 ;-).
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