RomRaider

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

You didn't base your work on Dale's latest, who ever you are. Also, you don't need me to be able to commit to your repo. Get in touch with me via skype and I'll help you fix your mistake such that you can help others in future.

The sharing method works through each pushes to and has complete control of their own. Each makes sure they're up to date with the latest/greatest from who ever is upstream (Dale). Dale then pulls in whatever he deems useful.

If you don't want to skype, do this:



If that goes smoothly, send Dale a pull request. If not, google conflict resolution and sort it out.

Fred.

I didn't want to base this of Dale's latest because I actually use these patches in my tuning. I hate to be on the bleeding edge of development when I am actually using the new version for working on ROMs. What do you suggest for this situation?

I removed you as a contributor so there should be no issue there anymore.

Thanks for removing me, I hate unnecessary responsibility :-) I wouldn't have abused it, though.

Fair enough re bleeding edge, for your use, but you can't expect the upstream to take out of date code and do the work of integrating it. What you need to do is make a branch of your "stable" version so that you don't lose it, make a new branch called bleeding or whatever, and make that match the stable one with your patch in it, fetch Dale's stuff, then rebase onto Dale's stuff and send that for merging.

So, if on your branch with your change, do this:



You shouldn't do a merge, only upstream should do merges, on a small project like this. You should only fast forward or rebase.

So effectively you end up with two versions of your patch, your old/stable/out of date one, and the new bleeding edge one.

Hope that helps, if you need to have a chat, hit me up on skype or google talk. My wrists are currently in bad shape and it's painful to type.

Fred.

Sounds good. Thanks for your help.

np :-)

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

Dale, time to fetch, review, apply, and push :-)


And/or between specific pairs of commits for a finer grained view, etc.

Now, if you've been good and your stuff is all public, then you can do this:


If you haven't, and/or you've got pending changes not committed, then commit them and do this:


And fix any conflicts if there are any.

To update that temp commit you made, if you had to make one


or to uncommit it and carry on working without it



And in any case, to bring your public stuff in line with Scott's, assuming it makes the grade, which I imagine it will:


Basically if you had stuff private, then I'd consider that your fault, so your stuff should get rebased as Scott has done the best possible job of making life easy for you. It would be unfair to ask him to do it again, and annoying to do it for him again and break his history.

I hope most of the above was unrequired and that I was totally patronising you, if so, great, if not, I hope it's useful :-)

Fred.

5 private commits unpushed! No rebase of them onto Scott's work. No fix up of Scott's formatting changes in a single post fast forward commit. An avoidable merge commit.

For the record, all though you say you merged in Scott's stuff without his formatting changes, what you actually did is create a merge commit that did two things:

1) merge the two code lineages
2) change formatting

This is bad as you effectively muddied the waters of his changes and the merge with your formatting undos. I know you meant well, but it was actually a bad move.

Scott's formatting changes (which I didn't even look at) are still there in history. And rather than one commit post merge, which you did anyway, another sad thing from my perspective, instead we have a merge with formatting changes and a formatting commit after it.

The 5 commits that you had private could have been rebased on top of scott's stuff, including a post scott commit by you to remedy his formatting. Until you pushed them the order they were in had no real significance. Now that it's all pushed that's it.

It's none of my business, really. I just worked hard to make the RR history as nice as I could and hard to try to make sure people knew what to do and it's disappointing to see this in the network view at 2am when I happened to look.

If you don't want my input on this stuff, I can just walk away, no biggy. I don't really want to now, though. But whatever, I guess.

Fred.

I had commits before and while he was working but could not make them public as I had no connectivity for the last 3 weeks.

I guess I just don't get Git...

Is it fixable now?

Excuse my grumpiness/sulkiness :-(

What you did is OK bar the "dirty merge" which is slightly bad. Take everything I say with "Fred's a fussy perfectionist/purist type" grain of salt.

I don't like merges at all where possible. SVN doesn't even have merges, btw. But merges are fine, really, and widely used. It's just that a linear history is easier to understand and test. Merges are harder to understand in the case where a problem is introduced in the interaction of the two code lines. Hence with git, it's possible to easily avoid them, so I do.

Git gives you the power of Rebase, which is what Scott did, and did correctly (twice, but he made it unclear on the first try by making a slight mistake after doing it right).

Rebase allows you to avoid a merge by moving commits forward or back onto a new base. You could have taken his and put them on yours, or you could have taken yours (that you hadn't yet publicised, and thus held no importance in terms of hash values) and put them on his. Considering he'd already done what he could, the latter was preferable, IF you want to avoid merges.

Try this: http://git-scm.com/book/en/Git-Branchin ... sic-Rebase

Rebase should ONLY ever be done on private commits, though. Once you share, that's it, leave them alone, or you screw up those down stream of you.

Again, sorry for being a grouch. Off to beach, much needed, I'd say.

Fred.