Category Archives: #git

Catching Up on GIT

Howdy all,

Luckily Jon and I have been working internships all summer using some sort of variation of a Version Control System.  I guess I didn’t learn as much as I thought in 401 for GIT as I really needed.  My git-foo has improved significantly (Jon’s is still way above mine, though. )  Right now I’m working on my james-dev branch (at least the one I push to) and usually branch when I’m trying something new.  I’m really digging the issue tracker but, I think one day this week I am going to take some time out, probably with Jon, and really get our Wiki in gear.

In other news, old news that I never mentioned, Joe was MIA for a while and I finally got in contact with him and he said he was too busy and couldn’t commit I emailed Karl about it but I never got a response, I’m sure he’s just enjoying summer.

From the blog jamescelona » WSU CS by jamescelona and used with permission of the author. All other rights reserved by the author.

The trickiness of using Git in an Eclipse project workspace

I know there is a Git plugin for Eclipse, but I prefer to do things the old school way with terminal commands. So when it came time to make sure my Eclipse project folder was being tracked by our remote repository on Github, I thought I could just clone our repository and then create a new Eclipse project in that same directory. Except Eclipse does not let you create a new project in a directory that already exists. And I wasn’t going to try to clone into a directory after it had already been populated by local Eclipse files; who knows what kind of problems that would have created.

If there is an elegant solution to this problem, I didn’t find it. I changed the name of the cloned directory, then created my Eclipse project using the original directory name now that it was unused and available. Then I moved all the Git files into the new directory, and deleted the now-empty one with the changed name. And everything works great.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Odd-sounding warning in Git is not a big deal

As I am preparing to make my first commits to our project, and I get bombarded with several of these warnings, one for every changed file:

warning: LF will be replaced by CRLF in res/layout/activity_main.xml.
The file will have its original line endings in your working directory.

I have no idea what this means. Luckily, Google had my answer here: LF stands for line feed, and is what Linux systems use to delineate newlines in files. CRLF stands for carriage return line feed, which is what Windows uses for newlines. That makes sense as I am working in Windows. It looks the impact of this change is pretty insignificant and the warnings can be disabled by entering the following in the Git shell:

git config core.autocrlf true

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Using Git in Windows

With our GitHub repository ready, and now that my Android development environment has been setup, it was time to install Git so I can actually start working. Git is a Linux tool and all my previous Git experience has only been inside that environment. But luckily Git has been ported to Windows, so I can use Git on my Windows machine without having to run it inside a VM. There are several options for running Git in Windows, and first I chose msysgit, the official Git for Windows project. I then abandoned that in favor of the GitHub application, which promised seamless connection to the GitHub website, including automatic maintenance of SSH keys.

The GitHub app has a nice GUI interface, and seems to be very easy to use. But I honestly haven’t used it much–the app also installs a Git shell, which I vastly prefer to the GUI. The Git shell emulates a Linux terminal, inside a Windows command prompt. Several of Linux commands are emulated inside the shell, such as cp, mv, rm, ls, cd, and others. Tab completion is also implemented which is wonderful. The emulated commands are not as powerful as their real versions (for example, typing “ls” works, but my preferred “ls -lh” doesn’t), but it’s still great to have this option. You can even open text files for editing from within the command prompt– just type notepad instead of nano or gedit. Lastly, a hugely useful addition to this Windows implementation that isn’t even in the Linux original:  the prompt in the shell uses symbols to help you keep track of your added, modified, and removed files, and changes color depending on your commit status!

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Organizing our GitHub repository

Our Android project will have an online repository hosted at GitHub. I’ve never used GitHub, though at work I use a local install of the similar Gitorious service. So far, we don’t have anything in the repo besides a GPL notice. The repository does have an integrated wiki that I have put some work into already. James and I discussed how to organize the repo and we decided we wanted to follow a professional approach that an actual project team working on commercial software might follow. Here is an excellent description of the model we will be using.

Basically, there will be four permanent branches. The first two branches, jon-dev and james-dev, are personal development branches that will hold snapshots of the project as we are working on it. We will keep our individual work separate in these branches so nothing one person does can affect the other. Here we also have the freedom to absolutely break the app while not affecting the snapshots in the next two branches. The code in these branches cannot be guaranteed to  build into a perfect working app, but that is to be expected because this is the entry point for brand new contributions.

The third branch, develop, is where James and I will merge our work from our individual branches after we have gotten our code working the way we want. Snapshots in the develop branch should build into a relatively stable app, similar to nightly builds in a major open source project, though bugs may still be present.

The fourth and final permanent branch, master, is reserved for major releases of the app. Once the code in the develop branch has enough features implemented, and has been tested thoroughly, it can be merged into the master branch and tagged as a milestone build. Apps build from code in the master branch should be considered stable and without major bugs.

We can also create temporary hotfix branches as we need to. For example, if a bug is discovered in the master branch, we can create a branch to fix the bug, merge it back into master after the fix has been tested, and then delete the temporary branch.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

My first conflict

So today I was doing some more documentation on the eutester repo. Everything was going fine until I went to push my changes to the repo. To my surprise, I received a conflict. Confused, i went to the github page to see if anyone had made changes to the file i was commenting. Sure enough, Marcos had made some additions to the comments. I tried to figure out how to fix the conflicts manually in my code but finally just decided to do a fresh clone of the repo and remove my old one. I normally do pulls before I get started on changing anything, I guess I just forgot to today and ran into a conflict because of it. At least I learned a little more about git due to this mistake, which is always good!

From the blog clacroix12 by clacroix12 and used with permission of the author. All other rights reserved by the author.

More Python

While things with infrastructure were being dealt with, I decided to jump on the eutester documentation project. So, during class I cloned the repo that kwurst forked and got to it. I took some time throughout the week to go through multiple directories in the eutester code and try to understand how it all worked and connected. I’m still not sure how everything works, but I do have a much better understanding of the code.

As far as documentation goes, I did do some in the eucaweb directory. The files i added to were the euwebaccount.py and euwebgroup.py. These are fairly basic scripts that setup accounts and groups respectively for testing purposes. Once I was done with commenting those for the day, i committed and pushed my changes to the repo. I checked the github page just to make sure and seeing my first push ever was pretty cool!

It looks like a few of us are doing good on commenting the code, so I wouldn’t be surprised if we had this project done within the next week. Now that I have a better understanding of the code I will be able to get some more commits in before the semester is over.

From the blog clacroix12 by clacroix12 and used with permission of the author. All other rights reserved by the author.

Meeting 4: Getting to know Git

So in this meeting, the class and I will be getting to know more about Git, which is a version control system for a project, more can be read on its official website git-scm.com or github.com, a website devoted entirely to Git. So first off, I have to have Git on my system, which is an Ubuntu OS. 3 ways to get Git: downloading from its site, using the command: apt-get install git-core, or using the software center. There was also an exercise that we got to do to set up Git, edit personal info, and played with a repository. It was my first time experiencing Git so there was some confusions in me but it was a good start. At least I know some basics through the exercise. So I’m going to go through the tutorial on the Git website to get a better understanding of the system.

From the blog longnguyen16 » wsu-cs by watever10 and used with permission of the author. All other rights reserved by the author.

All about git

Last week’s class was, for reasons that were made quite obvious, all about git. Just from the examples and small bit of experience we got with this tool in class, I can already tell that it will be extremely valuable for the remainder of the course, and my career as a computer scientist. Version control is a new topic to myself and going over the functionality of git made it fairly straight forward. It will take a little bit to get used to the commands to use git efficiently, but that goes without saying.

I actually think it would be a good idea to have CS students learn about git much earlier in their college careers and put it to practice in group coding assignments. This would provide students with a work environment for a project similar to the real world, long before they actually get there.

From the blog clacroix12 by clacroix12 and used with permission of the author. All other rights reserved by the author.