RomRaider

I had a hard time getting Scott's latest stuff into my branch. Mainly, I think because his update had a different parent than mine and the RomRaider master. Even Cherry-picking gave me errors which I eventually got sorted out somehow. Anyway, the point is, as you keep reminding everyone, rebase often to keep up. And it will make my job easier. It took more days to get Scott's changes in that it really should have.

Dale, you can just tell your downstreams to do it themselves. It should be decentralised in terms of workload. IE, Scott should send you a pull request only once he has his stuff on top of your latest. If you haven't pushed your REAL latest when he does that, you should rebase on to his instead. First in first served and most regular pusher suffers least :-)

Generally, rebase the smallest changeset, then the risk and headaches are least. Better yet: Synchronise WHAT you work on so you don't step on toes. Also, keep clean commits only, then you're MUCH less likely to get a conflict, even if working in the same file. Discipline is king :-)

Fred.

All my stuff was up to date with the master. I stash my changes to apply Scott's. In the GUI I can see Scott has a commit (035c41) BEFORE the merged with the master so the parent of the commit is different than all the rest. At least that's what I see, don't you?
I did try to rebase on Scotts stuff but no joy, error on, no common parent or something like that. I had to cherry-pick it.

The one before 035c41 with the green line coming in the bottom was the problem.



If Scott did that, you need to ask him to clean it up before you spend any time on it, as it's impossible to do nice things with a horrific merge like that in the middle. IE, review what you're trying to bring in, with a visual tree view, before you try to bring it in and just don't try if it's ugly/weird/wrong.

In any case, from a casual look, you did a good job tidying it up, full credit :-)

Fred.

Thanks.
I didn't think to look at it from his point of view. I was looking from the RomRaider master and mine and it did'nt seem as bad. This certainly makes it a bit more clear.

You're welcome, but the best idea is to use a tool like gitg that doesn't know who "owns" what, IMO. That way you're not muddied by the perspective (either one).



You can see two of the duplicated commits in that, and the two merges that messed it up, and which comes from where, and tags, and local branches, etc :-)

Oh, and it's fast, unlike github :-)

Fred.

This is the Eclipse view (with a couple extra local branch commits). It looks similar although the commit order by date seems to be a bit different.

Cool, yep, good enough :-) I prefer the gitg view or github view, but that works, as does gitk.

Dale, are you getting the notifications from Monaka?

https://github.com/RomRaider/RomRaider/network

There are a bunch of pull requests that are cleanly and individually rebased: https://github.com/RomRaider/RomRaider/pulls

Pull them in quick :-)

You'll have to rebase each on the last, however they're likely clean against each other.

Maybe I should transfer the account to you?

Fred.

I see them. I'll have to pull them and review.

That same guy just filed a bug on a Codehaus Maven plugin! He might be good to have around. Simply using maven is generally a good sign :-)

Maybe he can help me finish off mavenising RR :-)

Fred.

Fred does a good job at explaining some of these concepts but I found difficult to understand as I am not a git user.
I finally found a video that explains rebase and what it does.

Rebase explained.
http://www.youtube.com/watch?v=hjVeZkFvsEU

Rebase executed start at roughly the 5 minute mark.
http://www.youtube.com/watch?v=pMpfOcSC ... nO--4bWftQ


Here is how I rebase. Assuming you've forked romraider via git hub 2 months ago and want to update your fork/remote (example mine is https://github.com/walterstypula/romraider) with the latest changes from the official romraider remote (https://github.com/RomRaider/RomRaider) I also assume you've been able to work on your code locally on your computer. If you have any questions about this please ask I will try to explain this post as best as I can.

1) Open git hub console, navigate to your github directory, then execute the command "git remote" excluding the quotes. Likely you will only see origin remote which should be your fork. What we need to do is add a remote to original romraider fork.

2) Add the original romraider remote to your github remotes via the "git remote add <SOME MEANINGFUL NAME> <REMOTE URL>"
Ex. git remote add rrsource https://github.com/RomRaider/RomRaider

3) Next execute the git fetch command to download differential from the original romraider fork using the meaningful name you used in our example this is rrsource.
EX. git fetch rrsource

4) Next you actually want to rebase your fork/remote with the original romraider fork/remote, it is important to specify the branch in order to do this. You want to rebase off the original romraider fork master branch.
EX. git rebase rrsource/master

5) You will now see github start the rebase process by updating your fork to the latest codebase available from original romraider fork, then apply your changes on top of it. You will need to resync your changes to github and obviously test that you changes still work before you resync.

Hope this helps.

If you wish, it's also possible to do this in Eclipse IDE as well.
Switch to the Git Perspective in Eclipse.
Add a Remote and provide the Fetch URL of the new remote.
Complete the Fetch operation on the new remote.
With your local repository checked out, right click on it and select Rebase.
From the popup window select the new remote you added above.
The Rebase will start and finish as a fast-forward rebase if there's no conflicts.
If there are you manually resolve them and then perform the Rebase again.

For testing other's contributions I typically make a new branch of my local repo and apply updates from others onto it. If everything works then I'll apply the changes to may master and delete the testing branch.

Thanks, glad it was helpful.


This video is FULL of errors, and makes little bunnies (such as Fred) cry.

EG:

1 He states that master is going to be rebased ONTO the red branch, then proceeds to do the opposite. Bad for n00bs.
2 He draws 5 commits including the branch point in his first diagram and four in the second, and claims they are the same
3 He draws the commits from master on the branch as though they are different. I find this extremely unclear and misleading. It IS POSSIBLE to do exactly that, and it's a disaster when it happens. Yes, you can get the same commit twice and a merge in between.
4 When you do a "merge" after a rebase, it's not a merge at all, it's simply a fast forward or roll-forward of history on top of what already exists. No merging occurs. The merging, if required, occurs during the rebase, or, instead of a rebase.
5 Constant use of "yeah" to end every sentence. Welcome to the UK. Ugh. Having said that, this morning I heard someone say "he don't got it", any guesses where I am? Clue, your education system is badly broken. Another clue, will be in Dale's country in a few days.

Perhaps I'll do my own rebase explained video and publish it for all to see. I KNOW I could smash that guy's version :-)

Fred.