This is basically what I do too.
You need to do (only once): git remote add upstream https://github.com/nim-lang/Nim.git
And then, when I want to update my local devel branch (e.g. before creating a branch with some fix), I do: git pull upstream devel.
You still push your changes to your repo (git push origin <branch_name>), and then you can create a pull request.
Btw, it is not crucial that your branch must be ahead of Nim/devel (upstream) — this stuff matters only if you change some file that has also been changed there in the mean time.
Guys, awesome! Thanks a lot.
I did exactly what you suggested and it seems to have worked fine - so simple...
Now, one more question (I guess until I sit down and study how this thing works, I'll remain confused):
The local copy looks fine, the forked repo looks fine too.
Why does github show this message: This branch is 2 commits ahead of nim-lang:devel. ?
When I go to "Compare" to see what these changes are all it shows me is my 1 commit (which has already been merged to nim-lang:devel and the merge/push I just did from nim-lang:devel. So practically, there is nothing to be done.
Is there anything I have to fix in my setup?
a merge is also a commit.
However, if you are within a local branch and you want to update it on top of the latest Nim devel you need to:
# Go on your local devel branch
git checkout devel
# Check the remote names, I assume yours is called origin and Nim's is called upstream
git remote -v
# Sync with Nim devel (assuming Nim remote is called upstream)
git pull upstream devel
# Push Nim devel to your Github (optional)
git push
# Change to your local-pr-branch
git checkout my-pr-branch
# Replay your PR commits on top of devel
git rebase my-pr-branch
# Update your remote repo with the modified history, abort if someone that is not you also updated it
git push --force-with-lease
git rebase is much better than git merge because it keeps the history clean.
git rebase is much better than git merge for branches because it keeps the history clean.
Yes, please do not do merges if the commit history can be linear (using rebases, cherry picks, etc).
When you rebase, you are re-applying (or even re-ordering) the deltas elsewhere in the tree. A "merge-commit" resolves 2 lines of deltas into a bi-directional delta.