The swiss army knife of version control! People, meet git.

[evilbobthebob]

So, where do we report bugs now?

[jstump91]

So, where do we report bugs now?

Still on Google Code; only the code has moved, and even so, we're going to merge it back into the current svn from time to time. The bugtracker and wiki are still in the same place.

(When I have a suitable moment, the first such merge-back will occur.)

[evilbobthebob]

Right, so bug reporting is still on Google Code. How are we going to know when something has actually been committed to the trunk and/or a branch? Is it going to be announced each time, will there be an RSS feed, or will we just have to guess/update every day? I'm assuming the first; I'd prefer the second option.

The only problem I'm seeing with git is a total fragmentation of development as each developer pursues their own ideas for FoFiX safe in the knowledge that it won't conflict. I see a problem occurring, as these ideas never get properly merged because they aren't finished for whatever reason, so we end up having to pick and choose which branch we want for which bugs are fixed/features included. I'm sure the dev team is capable of much better planning than I'm giving you credit for; however, everyone else committing their own changes won't be under that kind of control. I suppose it won't matter so much for a smaller project like this, because there aren't hundreds of python developers on the forums all ready to jump on the commit button. Only time will tell if this all works out. I am most likely being pessimistic.

[death_au]

There is an rss feed on github: http://github.com/feeds/stump/commits/fofix/master (that's the master branch feed)
And just as before, devs should mark google code issues as fixed when they fix them.

[evilbobthebob]

Thanks very much death_au. Now I just need to work out the whole updating thing :P

Well apparently

Code: Select all

git pull

alone doesn't work, I have to specify the repository as well, for some reason. Also, if I get the SVN version of a theme and I run the git GUI, all the theme files show up as unstaged, and there doesn't seem to be a way to make them "ignored" like in SVN. Maybe I just need to read all the documentation. Woo.

OK, if FoFiX is what you use git for, run these commands in git Bash once you've cloned the repository:

Code: Select all

git config branch.master.remote fofix

Code: Select all

git config remote.fofix.url git://github.com/stump/fofix.git

Then you really do only need to run

Code: Select all

git pull

from a git Bash on your FoFiX repository folder to update to the latest master revision.

[Syfatalityz]

Duuude, git is 8x faster than SVN for me

[evilbobthebob]

Yeah, it's certainly fast. Thanks for setting songs/themes to be ignored, jstump. Cleans up the git GUI nicely.

[death_au]

Thanks for setting songs/themes to be ignored, jstump. Cleans up the git GUI nicely.

http://github.com/stump/fofix/commit/f8 ... 697070c010
I think you'll find akedrou did that

[evilbobthebob]

Yay akedrou is committing again!

[666shadowlord666]

I kind of miss the clean organized look of SVN personally. I just am finding it hard and sloppy looking when trying to look at changes (checked out svn daily with previous ways.) But hey, i know this is better, so i will try to get used to it.

[lagwagone]

Small changes I had to make in Fofix.ini after making a fresh windows install and cloning the repository:

1. set ThemeName = MegaLight V4
2. deleted the base_library = line
3. set SelectedLibrary = E:\songs

Don't know if I somehow managed to end up with an old Fofix.ini file but maybe this will help someone having trouble getting to the gameplay screen.

[death_au]

For that first one, there's something wrong with the default megalight theme. It uses something in it's CustomTheme.py that got broken in an update somewhere. It's the same on the SVN, too.

[jstump91]

For that first one, there's something wrong with the default megalight theme. It uses something in it's CustomTheme.py that got broken in an update somewhere. It's the same on the SVN, too.

That brings to mind another awesome and quite useful git feature that svn doesn't have: "git bisect". (Binary-searching a range of revisions to see where something broke is tedious with svn, but git does all the hard work for you. You just have to tell it whether it works or not at each step.)

I am doing that right now to see where exactly MLv3 got broken and potentially fix it if the fix turns out to be trivial (since I'm not really a themer).

edit: r2013 / git ff34877. I gave more details in IRC, but I don't have time to make the fix at the present moment. I will once I can if nobody beats me to it.

[KaelemGaen]

Probably a silly question, since I don't see an alternate, but can msysgit work on a 64-bit Windows using the 32bit installer (unless it has 64-bit and just wants to install in Program Files (x86).

[raynebc]

If it installs to the "Program Files (x86)" folder by its own choice, then it is 32 bit and Windows redirected it there. This issue:
http://code.google.com/p/msysgit/issues ... %20Summary

Implies there is no native 64 bit version, but that the 32 bit version will run with some limitations on 64 bit Windows (ie. shell extensions don't work).