Skip to content

Submitting Bugs & Using Git

February 13, 2011

So far ive completed both my popcorn.js bug and my processing.js bug, which are both under peer-review as of right now.  After working on both projects its hard to say which one I enjoy more, as they both have there cool sides.  One of the things I completely forgot about when coding my fixes for these bugs was the formatting that goes along with each one.  I just blindly wrote code the way I would and assumed it would be sufficient for everyone else, which was not the case.

 

After submitting my popcorn bug for review, I got a reply back from Anna saying that the branch I worked on when working on the bug was out-of-date and that it was missing some small changes from the most recent release of popcorn.  I would have to create a new branch for 0.4 of popcorn, and make a branch of that for my bug (which I forgot to do in my most recent commit 😐 )  After committing, I got an email from Rick about indentation issues, using tabs instead of of 2 spaces (which anna also mentioned), and using single quotes and double quotes inconsistently.  I read the style sheet over and fixed the problems that I created.  I’ve always heard teachers tell me that one day I would have to abandon my formatting and be forced to format to the specifications of the project I’m working on but it always went in one ear and out the other.  Now that I’m working on open source projects that include people from all over north america (the world?), I can see the importance of creating a set of guidelines for everyone to follow and why its so essentially we all adhere to them.

 

Also after doing numerous commits, pushing to my remote, checking the status of my branch, and dealing with conflicts and merging, I can finally say that I like git!  It was very confusing at the start and didn’t really understand alot of what I was doing, but after actually using the commands in practice a couple times I began understanding what was happening and how powerful git actually is.  In the beginning I was always afraid to commit.  I had the mindset that if I commit, it should be flawless, which I now understand doesn’t need to be the case.  Commiting often lets you track changes in your code, and revert back to any previous commits if need be, giving you a detailed time line of what you’ve done thus far on your project.  Merging in git is also quite simple.  If there was a conflict that git couldn’t resolve on its own, it ask you to solve the conflict and then commit again.  When you go to edit the files that are in a conflicted state, it is clearly outlined what is from HEAD, and what is from the branch your trying to merge.  You then select which one you want to use by deleting the other.  Commit again, and your good to go.  I also find the combination of git & lighthouse to be amazing.  Being able to push to my remote, quickly grab the commit sha, and post it on lighthouse for review seems to work smoothly.

 

I must say that after completing these two bugs, it is the first time so far that ive felt like a “hacker” as David Humphrey calls us.  I found some code on the internet somewhere, chose what was useful to me from the code, chopped it up, and made it into a function part of the open source projects im working on.  Pretty cool feeling if you ask me.

Advertisements

From → school

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: