Robot Ninja

Another item to consider is looking into GitFlow.  It is not a part of git itself and is just a way to work which survives in complex dev environments.  See: http://nvie.com/posts/a-successful-git-branching-model/ for more information.  It is pretty similar to how we ended up doing things on some insane large projects I've worked on but with the addition of some scripts: https://github.com/nvie/gitflow#readme, it makes things fairly easy compared to our adhock methods in Perforce.  An added benefit, if you happen to use Os X, SourceTree (my favorite git front end for OsX) integrates the scripts directly.  Point and click git flow is really sweet.

Wow, GitFlow makes working with development branches really nice. I've been using GitExtensions because it provides an easy interface for git and I like how it presents the repository graph. I noticed that there's a request to integrate GitFlow into GitExtensions, but it doesn't seem like anyone is trying to implement it. While GitFlow would be really nice to use, I'd rather stick to GitExtensions for now than go back to using the command line for Git. So far I'm really the only one working on this project, so I'm the only one modifying my repo. I will of course adopt the same branching model into my project though. Also I'm certainly open to recommendations for other Git GUI extensions, especially if they have has successfully integrated GitFlow.

*EDIT*
It seems like SourceTree (http://sourcetreeapp.com/) has already integrated GitFlow into it's Mac version, and are working to get their Windows (beta) version up to speed. They're not quite there though, so I guess I'll just stick with GitExtensions for now. I also came across an article by Scott Chacon, where he talks about an alternative version control scheme to GitFlow. His team uses it at GitHub. Here's the link for anyone interested: http://scottchacon.com/2011/08/31/github-flow.html. I *think* the GitFlow model still seems more fitting for my project though...
 

Also although I'm writing an editor, I'm also building engine code in the same solution. I ended up having separate local repos for each project in the solution. Is it recommended to have one unifying repo instead? It would definitely make keeping track of changes much easier (since there would only be one repo to commit to), but I don't know if there's a big negative that I haven't thought of.

With Git you can use Rebase to clean up your commits before pushing to your remote.

 

http://www.reviewboard.org/docs/codebase/dev/git/clean-commits/

 

 

For branching I like to open up an issue ticket at GitHub for the feature I'm working on, create a new branch with the title 'iss01', then merge the branch to master and close the issue when it's done.

What a great resource. It answered so many questions, and some I didn't even expect. Thanks!

I agree with TheChubu. This interest in asperger's is becoming the next "ADD". I think this is just a sign of the age we are in. Technology is more integral to our lives than ever before, and so lifestyles are changing because of it. Our brains change as a result of our lifestyle and the activities we choose or choose not to participate in.

As a loose example to explain what I'm trying to say, not too long ago we believed that there was a part of our brain that allowed us to recognize human faces. As it turns out, evidence today suggest that this is not the case, but that we are able to recognize human faces simply because we are always around other humans. Our brain adapts and allows us to recognize subtle facial details among different people. This explains how a person can have such an easy time differentiating between different people from their own race, and yet have such a difficult time telling people of another race apart. It also explains how a car enthusiast can easily differentiate between cars of different models/years, or the fact that we can see faces in cars. (Haha, I kind of went overboard with my example.)

Anyways, I'm not saying I'm correct in this issue. I'm just proposing a theory based on my experience.

I am also curious if Art History was your only choice to fulfill your Humanities course requirement. At my university, we were provided by our advisors at orientation with a class schedule for our majors that listed which courses we could generally take to fulfill parts of our requirements for our degree. I would find it hard to believe that the class your taking was the only one available, unless your schedule did not permit you to take any other classes. On the other hand, perhaps you initially thought Art History was the best choice out of the ones you were provided. Whatever the fact, I just hope that you won't base your opinion of every other Humanities class on your negative experience with this one.

I come from a Humanities background (Psychology to be specific), and of course there were such courses that I tried to avoid. Funny enough, I declined from taking Art History. Don't get me wrong - I can really appreciate art, and I admire artists every day for all of the work they produce. The "history" element was what made me hesitant. Anyways, it's unfortunate that Art History is not an interesting subject for you, but we all have our own taste in things. Like others have suggested, if you still must fulfill another Humanities requirement, or if you need some extra units and are up for it, try out a course in philosophy, music, cultural/ethnic studies, gender studies, psychology (my personal favorite!), or hell, even another art class (something more hands on - i.e. drawing, painting, photography). Try whatever you think will interest you the most by the description of the class, or ask one of your friends if they took a course that they found particularly interesting.

Finally, I want to sort of clarify further what I think a lot of comments are saying regarding interacting and socializing with others out in the world and workplace. As a Computer Science student you may be able to think of dozens of different ways a computational problem may be solved, but I can almost guarantee that some of the perspectives that you are exposed to in the social sciences would flip your world upside down (even if momentarily). Like how you must approach a CS problem from different perspectives to come up with the best solution, oftentimes you must approach life and other people from a different perspective. Like anything else, it's difficult to know that such perspectives exist until we are exposed to them. Good luck! 

P.S. Sorry for the essay! 

I too have an interest in real-time rendering, but I had no idea that this was the nature of academic research vs industry research. I'm applying to become a student volunteer at this year's SIGGRAPH hoping to get more insight in the field. I guess most if not all the research will be geared towards offline techniques? It will be awesome nonetheless! *EDIT* I take that back, SIGGRAPH has featured quite a bit of real-time work.