How to be the guy in “git.txt” (Part 2)

A few months ago, I made a blog post called ‘How to be the guy in “git.txt,”’ referencing the mouseover text of a certain xkcd comic. Here I’d like to expand on that and provide more useful resources.

  1. First, read this tutorial. It discusses different workflows you might use with Git, building up from simpler to more complex workflows. It helps you to understand the idea behind what you’re learning before you really plunge into it.
  2. Next, I again recommend Pro Git, a free online book on how to use Git. You don’t have to commit to reading the whole thing, but just skimming the first 3 chapters can make you much more knowledgeable about Git.
  3. Search the web. Seriously. If you have a question about Git, chances are that someone has already asked it (on StackOverflow, probably). You can learn a lot just by wondering, “How do I do this in Git?” then looking it up. (This really goes for any programming tool.)
  4. man git. I wouldn’t recommend using man pages to learn Git, but they are very useful as a reference. To view the manual page for a specific git command, for example, git merge, use git help merge.
  5. Lastly, I’ll leave you with a cheat sheet I found.

Setting up Deep Learning for Java (DL4J) on the Lab Computers

Getting up and running with DL4J in the lab is very easy.  To begin with, you will need the maven plugin for eclipse.

The maven plugin is called m2e. The following steps explain how to install it:

  1. Open eclipse and go to Help -> Install New Software…  You should see the following screen:
    Screenshot from 2015-10-07 19:18:09
  2. In the field labeled “Work with:” enter the following url and hit enter:
  3. You should see Maven Integration for Eclipse in the main box. Check it and click next until you get to the license agreement page. Read through it and then accept the agreement and click finish. At this point m2e will be installed.

After successfully installing the m2e plugin for eclipse, simply follow this guide to finish setting up DL4J:

3D Engine for Geometry

Our project is up on the GitHub. Please follow these steps to import it into Eclipse:

1. Within Eclipse go to File -> Import
2. Select “Projects from Git” under the “Git” folder and click Next.
3. Select “URI” for the location, click Next
4. Use this location:  (Copy-and-paste that location into the appropriate box within Eclipse. You don’t need to click on the link…) There is no need to enter a username or password at this time. Click Next.
5. On the next screen, select the “master” branch, and click Next
6. Select a place to save your project. Probably the default is fine. Click Next.
7. After it finishes reading our project, select the “Import existing projects” wizard, and click Next.
8. Select the “Geometry2014” project, and click Finish.

That should do it. Depending on your Eclipse settings, you may need to select a JRE System Library within Eclipse. To do this, within Eclipse, select Project -> Properties to bring up the Properties page. In the left margin select “Java Build Path.” And within the “Order and Export” tab, select the JRE that you wish to use, and click OK. Then everything will work perfectly.

The Arena class has the main method that launches the 3D engine. Run “Arena” as a Java application to see the world.

Eclipse, Kepler version, on your Ubuntu desktop

(This is a post from Brian McCutchon.)
All of the computers in the lab have Eclipse Kepler installed on them. Unfortunately, it is not installed in a convenient way. This can be fixed by running the following command from the terminal:
cp /home/share/vision2014/eclipse.desktop ~/Desktop/
This will copy the eclipse.desktop file to your desktop. It adds a desktop icon for Eclipse Kepler. If you want to also add Kepler to your launcher, do the following: 
  1. Right-click on Eclipse in the launcher and select “Unlock from Launcher.” This removes the old Eclipse. It may not be necessary for you if you have not added Eclipse to your launcher.
  2. Open Eclipse Kepler from its icon on the desktop.
  3. In the launcher, right-click Eclipse Kepler and select “Lock to Launcher.”
Warning: Do not remove the desktop icon. If you do, the Launcher icon will also be removed.
For those who are interested, here is the source of eclipse.desktop:
[Desktop Entry]
Name=Eclipse Kepler

It is an Ubuntu desktop file.

Git Workflow, by Brian McCutchon

This git workflow for Eclipse is based on the git Centralized Workflow as described here:!workflow-centralized
Before you start, you should read the section entitled
Minimizing Conflicts.”


Minimizing Conflicts

If two people begin working on the same files, conflicts may occur. Rather than fix large file conflicts, it is best to keep your local repository synchronized with the central repository so that, if they do occur, these conflicts will be smaller and more easily resolved. To do this, you should push and pull changes often when connected to the central repository and making changes.

To edit an existing file or files:

  1. Edit the file(s).
  2. Whenever you make a significant change,
    commit it.
  3. When you are ready to share your changes with the team,
    push your changes upstream.

To add a new file or files:

  1. Create the file(s).
  2. You should commit the file when it reaches a state at which it serves its most basic function. For graphics, this could be anything from a placeholder image to a fully developed graphic. If you are creating a placeholder image, it is best to give it the name it will have when it is complete, i.e. “logo.png”. Then whoever replaces it with the final copy can simply overwrite “logo.png” without the need to modify the code where “logo.png” is referenced.
  3. When you are ready to share your changes with the team, push your changes upstream.

To delete a file:

  1. Delete the file from Eclipse.
  2. Open/go to the Git Staging view. The file you deleted should listed in the “Staged Changes” area with a small gray “X” in the bottom-right corner of its icon.
  3. Commit the change.

To push changes upstream:

  1. Press the “Push changes to upstream” button. It depicts a straight red arrow pointing to a yellow cylinder. This can also be done by right-clicking on the project and selecting “Team > Push to upstream.”
  2. A loading bar should pop up, followed by another dialog box. If you see the message “master: master [rejected – non-fast-forward]” in the center pane, it’s time to rebase. Otherwise, you’re done.

To pull changes/rebase:

  1. If you haven’t already done so, configure pull to rebase by default.
  2. Pull changes. This can be done by clicking the “Pull changes from upstream into current branch” button (red arrow pointing away from yellow cylinder and downward in the toolbar) or by right-clicking on the project and selecting “Team > Pull.”
  3. If conflicts occur, you may have to resolve them manually.

To configure pull to rebase by default (modified from an answer by robinst on Stack Overflow):

  1. Open the Git Repositories view.
  2. Locate [Your Project Name Here] > Branches > Local > master.
  3. Right click on it and select “Configure Branch…” from the context menu.
  4. In the dialog that appears, check the “Rebase” box and press “OK.”

To commit a change:

  1. Open the Git Staging view.
  2. In the Unstaged Changes section, you should see a list of the files that you have not committed. Move all files on which your commit depends to the Staged Changes section.

    IMPORTANT: Make sure that you include all files on which your main commit depends. For example, if you add a method to class A which uses a new method that you added to class B, you must include B as well as A. Otherwise, other people may end up with a copy of class A that will contain errors. This also applies for images: if C.jpg is referenced in class A, you must also commit C.jpg. As a general rule, it is best to commit everything that you have changed.
  3. Write a meaningful commit message (see below).
  4. When you are done, press “Commit.” If you are connected to the repository and wish to share your changes, you may press “Commit and Push.”

Here are some guidelines for writing good commit messages (taken from this
blog post

  • The first line of the commit message should be a short description (50 characters is the soft limit), and should skip the full stop
  • The body should provide a meaningful commit message, which:

    • uses the imperative, present tense: “change” not “changed” or “changes”.
    • includes motivation for the change, and contrasts its implementation with previous behaviour.

I will add that the body is optional, but should be generally included in the case of code changes. Here is an example (contrived) commit message:

Add collision

Create the class CollisionChecker, which stores information about the physical environment and can be used to determine whether two objects have collided. Previously, the game had no method for determining collision, allowing players to pass through walls, etc.

References/Further Reading: