Hi Howard,
No, I am not offering help, but asking the same question. What does rebase do?
Joseph
(Please excuse the ASCII art ;) ) Say Moodle has the following commits:
- M1 - M2 -and you start developing at this point
- M1 - M2 - H1 - H2 -While you're developing, Moodle also makes some changes
- M1 - M2 - M3 - M4 -
A merge will do this:
- M1 - M2 - M3 - M4 - * -
\- H1 - H2 -/
That is, it will create a new commit that tells git that two branches have been merged.
A rebase will do this:
- M1 - M2 - M3 - M4 - H1' - H2' -That is, it will rewrite your changes so that they apply on top of the end of the tree (M4), instead of apply onto M2. (H1' is a rewritten version of H1.)
Now, if you keep developing off of the rebased version:
- M1 - M2 - M3 - M4 - H1' - H2' - H3 - H4 -and Moodle keeps developing:
- M1 - M2 - M3 - M4 - M5 - M6 -
If you rebase again, you will get this:
- M1 - M2 - M3 - M4 - M5 - M6 - H1'' - H2'' - H3' - H4' -In other words, it rewrites all four of your commits to apply on top of M6, instead of M4.
If you try to push now, then github has:
- M1 - M2 - M3 - M4 - H1' - H2' -but, the trees have 'diverged', so it doesn't know what to do.
To decide what to do at this point, you need to consider how your actions affect 1. yourself, 2. the Moodle tracker issue you're working on, and 3. people (if any) who have cloned your tree.
Some options that you have are:
- M1 - M2 - M3 - M4 - M5 - M6 - *
\- H1' - H2' - H3 - H4 -/
which git would understand how to handle when you do a push, because it has "- M1 - M2 - M3 - M4 - H1' - H2' -" as a sub-tree. Aside from having to build a time machine (or figure out how to get git to go back in time), this is also easy on yourself, and would also be easy for anyone who has cloned from your tree. I do not know how it would affect the Moodle tracker issue -- maybe a core developer could comment.Basically, if nobody has cloned from your tree (or you don't support people cloning from your tree), option 1 is the best -- rebasing gives a nice linear commit tree. If other people are cloning from your tree, option 3 is best, as long as it doesn't hinder the Moodle tracker issue too much. If it does hinder the Moodle tracker issue, and you need to support people cloning from your tree, then you may need to manually maintain two branches -- one for option 1 and one for option 2.
git push -f {branchname}
The -f option tells git that you are sure you want to push the re-written history. (Doesn't the error message suggest using -f?)
Git's not too bad once you know what your doing, its just the commands arent that obvious, personally I prefer mercurial as its essentially the same thing, but with a more user friendly front end. However if your interested in a more comericial git support option I'd recommend Clearvision-CM
One of my branches in my forked Github Moodle has been merged in the main project. (http://tracker.moodle.org/browse/MDL-31903)
It is instructed here that you should delete the merged branches from you repositories.
I first did this to get my repositories up to date...
-----------------------------------
git remote add upstream git://git.moodle.org/moodle.git
git fetch upstream
git push origin refs/remotes/upstream/MOODLE_22_STABLE:MOODLE_22_STABLE
git push origin refs/remotes/upstream/master:master
git checkout master
git merge origin/master
----------------------------------------
Then I did this to see which branches were merged:
git branch --merged upstream/master
It just prints:
master
What to do?
