RomRaider

I started by doing this, to get where you are:


Just for context I ran:


The hash is the last SVN hash, and the ^ means "the one before this" which I did such that the last SVN one is visible in the process, despite the fact that we don't need/want to touch it.


Is what appears. And this is what I leave in place:


Note, all I did was delete the two lines with your commits on them (and the instruction comments). The merge didn't show up, I assume that it knows that it was an auto merge or some such thing. And this is the output that I got:


So then I did this:


So if we look at network now, it shows this:

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



And if I run this:


Those are the differences. IE, I added a cp command to the script (feel free to remove it in a legit "getting rid of fred's hacks" commit) and my ignore has more stuff in it. You can change that too, if you want. The main point is to do it cleanly :-)

If you want to try it, go ahead, I have your original still in my repo and the one i did on github and in my repo locally here. IE, you can't do any harm.

If you're happy with what I've done, just move any new changes out of the way (try git stash out for test drive?) and then clean up with:


And if you wanna update the official one:


Where 3c55eaa531be60ae6ccdf1ad51c1e2083ac5aecf is the hash of the commit you did, post my clean up.

Hope that's not mud and more like Riedel crystal :-)

PS, I have a guest arriving around 8pm my time, or a bit before. Let me know if you're still up for a chat and if you can manage it before then.

Fred.

The key thing above is that git took care of it. For me, it was easy, hit enter, hit down, hit dd twice to remove the lines, :wq to save/quit, done. :-)

If you do wanna change what I did, reset to that hash first, then make the commits, then push it all up once satisfied.

Fred.

I want a repository for the RomPatch utility... should that go under RomRaider, or should I put it under my own github account?

RomPatch is a command-line utility for patching ROMs (adding SD, LC/FFS, etc). It's completely independent of RomRaider, and written in C#, so maybe it belongs outside of github.org/RomRaider. But 100% of its users are RomRaider users, at least so far, so I dunno.

I started it, and Merp is working on it now as well, and PMing zip files isn't really ideal, so github seems like the next logical step.

Also, is there a way for two git users to send changes back and forth for review, without checking them into the repository? For example, at work I would request a code-review by emailing a package-file to my team, and they can use it to view my changes (relative to what's currently checked in). Is there something like that for git?

I've used bzr and hg for solo projects, so I'm familiar with the basics of distributed version control, but I've never used either of them to collaborate, and I haven't tried git yet. Unless you count signing up for a github account, which I did 5 minutes ago.

Thanks!

Fred probably has a better answer, but I'd say create your own GitHub account for the stable version, you can share it with Merp as a contributor and both of you can push to the same repo. And/or Merp can fork yours, make changes and you can review them from his fork (as a remote) against yours and merge them into your local repo if you wish and then push them up to your public repo. Plus you can always have a branch for your in-progress work and when happy merge them back to the main branch (master).

Wow! I think I actually understand what I wrote... cool! Have a read of this quick Git intro: http://wiki.eclipse.org/EGit/Git_For_Eclipse_Users (it's not really Eclipse focused as the URL suggests).

Excuse brevity, wrist is still iffy from RSI. Make your original repo on your account. Merp gets his own account (necessary for him to upload ssh key). It's fine to have a copy forked on the RomRaider account with you added as collaborator assuming dale is fine with it, but that'd only be to let people find it more easily, which likely isn't necessary.

Re merging: Don't. If you can possibly help it, do rebases only to maintain a linear history.

HG and Git are similar, so you should be fine. Collaborating just means bringing in changes from other repos, no big deal. In terms of that:

One gate keeper only! IE, only you should have push access to the official repo for your project, and you bring Merp's work into your copy to check it locally before publishing it there.

Re sharing changes, unless it's private, temp branches are the way. If it's private you have choices:

Setup own git server and push private stuff there.
Pay github for a private branch/repo.
Generate a patch and email that.
Possibly other things.

Git is god in source control :-) You'll not go back once you feel the power :-)

If I missed something, ask again and I'll reply tomorrow. Just got home from cruising the entire city on foot all day with a friend, great day :-)

Fred.

So this won't work on my public repo right, I can only do it locally (which I believe I did successfully use cmdline tools, you should be proud ). For my public repo to reflect this change what is the best option, delete and re-clone and apply the change?

My only concern with the cp command is that the run.sh script is really meant for the Linux ZIP distrubtion version, such that the user can run RomRaider from a cmdline. If you wish to run it from your local repo after a build then we should find a different way to invoke RomRaider, we should remove it or add
if [ -e build/linux/lib/RomRaider.jar ]; then
cp build/linux/lib/RomRaider.jar .
fi


Not mud but not crystal either.

I created a Git account and test project last night to familiarize myself with the system, pretty nice indeed! I would eventually like to use it for version control of ecu patches / definitions, and of course working on RR and RomPatch

OK, you're missing some understanding about git.

Your local copy isn't a copy, it's an entire stand alone repo. The only things you can do with remote (also entirely stand alone repos) are push and fetch. All operations on git, bar those, are always local. The clone command does what it says, it copies the entire repo verbatim to your disk. You mirror it by doing that.

Glad you figured out how to do it. If you added my remote and fetched it, then you can diff the hash at the head of yours and the hash at the head of mine, and although the hashes are different, the code should be identical. IE, git diff hash hash should return nothing at all.

Re fixing the repo, no need to delete it etc, just "git push --force" :-) That overwrites the pointer to a hash that master refers to, effectively meaning that master becomes that.

Branches aren't special. They're free and cheap and it's normal to use branches liberally in git, unlike SVN where they were excruciatingly painful. There is no real difference between master and OMG-a-new-branch or whatever else you might call it. master is just the default. just like origin is the default remote, also otherwise not special.


Not arguing at all. Just wanted it to get fixed in a distinct commit post sorting out the state of your repo, that's all. Wrote a suggestion, deleted it, script is likely somewhat temporary in its current form anyway.


Better?

Here is something that I wrote about git a while back, maybe it can generally help:


master is just a branch which is just a label for the hash that it points to. When you push --force you say "set master to X hash even though X hash is NOT a descendent of the current hash". If it was a descendent, then you'd not need the force option - it would just fast forward.

I hope some of that helps a bit.


Fabulous idea! Start a thread on this specifically, I gather it would require a bit of work assembling the info.

Fred.

I'm sure I'm missing quite a bit still, but you answered what I needed to know, i.e.: the --force option. I didn't think about that one.

yes agreed, but I'd still like it to work correctly without undue errors.

Looking good! :-)

That sticky thread needs to be pluralised! :-) "legacy SVN repositories" ;-)

Time for documentation updates on the website etc too, I guess.

Hooray! Phase one of my cunning master plan has been a success. On to phase two.

Fred.

I've fixed up the wiki site with the new build instructions for devs.
http://www.romraider.com/RomRaider/GettingStarted

I've kept it simple and based it around Eclipse as it has all you need to get and build the project. If someone wants to use other tools/IDE then they can work out the differences themselves.

One last thing, how can we differentiate a build from one commit to the next? With SVN we have the commit # from the repo. Can we get a similar reference to use from the official Git repo based on the value of the user's HEAD parameter after they've cloned the repo locally?

Yes, you can probably just pull the commit hash from a file in the .git repo, where ever that may be. The best way is to use git describe, though, as I did in my first hacking on the ant script.

.git/refs/heads/master

contains the hash of the current master head commit which is what you want IF you're on master, which you probably will be. I really don't like that approach, though, as it means you can't do a build from a branch and get an honest hash.

git describe ftw.

Interesting thread. I think I suggested using git last year in the thread about improving romraider but no response.

At any rate, will commits be handled like the Linux Kernel code here? If so, who is responsible for pulling changes and making a final official release of romraider? Who is the Linus Torvalds equivalent? I was not able to find this in the thread but maybe it's qoncept? If you are not doing this then why not?

NSFW asked about pre commit code reviews. There is less need for this than with svn because git works by pulling changes from one user to another. i.e. make a local branch, pull thier changes and try them out, when done delete the branch. However, there is a tool called Gerrit which can be used for such reviews.

Dale is in charge/Linus for the moment, at least :-)

No need for a temp branch for reviewing others changes. In fact, you don't even have to check those changes out if you don't want/need to. You can just fetch and review by diffing different hashes until you're happy.

I'd love to see a code review process in place more officially, though this isn't the place to discuss it. If you're super keen, start a thread, I'll get involved :-)

Fred.

Ok great, makes sense it's Dale . Will Dale then be pulling in all potential changes from those of us with a local repo? I only ask because I have some minor changes to share...

Usually at work when I want to try out (i.e. test them to make sure things are not busted), someone's changes as opposed to just reviewing them, and not pollute my own local area, I make a branch then pull to that branch from my colleagues git repo and try them out. When I'm done I delete the branch. I just find that workflow safer. The added benefit is I can make changes to their changes then they can pull back from my repo. This stuff is the power of git vs svn.

Maybe you are right we could have another thread about code review. It's always an interesting topic.

Dan