This assignment will give you practice in working with the GitLab forge and will also serve as a check that you have been following along with the Lab activities so far.

1. To work with private projects in GitLab you must register a public ssh key with your account:

   1. Generate an ssh key pair.

      Do use a passphrase on this key.

   2. Log into the CS350 GitLab or to the CS Dept GitLab.

   3. In the window toolbar, upper right corner, is an icon or picture denoting you. Click on it to drop down a menu and select Settings.

   4. Select “SSH Keys”.

   5. Open your public key in an editor and copy and paste it into the Key text box in GitLab. Give it a title. Click the Add Key button.

2. Fire up your installation of Eclipse.

   1. Next you will register your private key so that Eclipse can supply it when you do git-related operations.

      Go to Window $\rightarrow$ Preferences $\rightarrow$ General $\rightarrow$ Network Connections $\rightarrow$ SSH2 $\rightarrow$ General. Add your private key.

   2. You also want to tell Eclipse what name to send to GitLab to identify yourself when committing. This is critical if you want to get full credit for your team contributions during the project later in the semester.

      Go to Window $\rightarrow$ Preferences $\rightarrow$ Team $\rightarrow$ Git $\rightarrow$ Configuration. If you see existing entries for user $\rightarrow$ name and user $\rightarrow$ email, edit them as follows. If you don’t see them, use the “Add Entries” button to add them as follows:

   | key | value | | :—- | :—— | | user.name | your CS login name | | user.email | your ODU email address |

If you find yourself working on different copies of Eclipse (e.g., on different machines), you will want to repeat these steps for each one.

1. In Eclipse, enter the “Git” perspective (from the Window menu).

2. In GitLab, return to your project home page. Use the Clone button to copy the SSH URI of your project.

   In Eclipse, click the “Clone a Git Repository” button and paste the project URI into the appropriate box. (It will probably have already been auto-pasted there.)

   For User, enter “git”. Leave the password empty. Click Next.

   The ssh key you previously registered with Eclipse should get you access to your project. Right now it should only have a “master” branch. Click Next again.

3. Choose the directory where you want to place your project clone. (And remember it.) For thye purpose of this assignment, let’s keep it in a directory named gitlab1, but you can put that directory anywhere that is convenient.

   Then click Finish.

   Now look in that gitlab1 directory.

   • You should see that it contains your README.md file.
   • If you are on a Windows PC, you will also see a .git directory. That’s where the git command keeps all of its history information.
     • Never, ever touch anything in that directory directly.
   • If you are on a Linux or MacOs machine, you won’t see the .git directory because file names that start with “.” are hidden unless you specifically seek them (e.g., with an “ls -a” command.)

4. Download this zip file, containing the Java source code of a simple project. Unzip that file, placing the results into the GitLab1 directory where you placed your project clone in the previous step.

You should wind up with a directory structure that looks like this:

    gitlab1/   
    ├── .git/
    │   ├── (pay no attention to the man behind this curtain)
    ├── README.md
    └── relativePaths/
    │   ├── src/
    │       └── RelativePaths/
    │           └── RelativePath.java
    │           └── ShowRelative.java
    │           └── TestRelativePath.jaba
    └──relativePaths.zip

Make sure this is what you have.  When you are certain, delete the `.zip` file.

1. In Eclipse, return to the “Java” perspective.

   Follow the usual procedure for creating a Java project, specifying the location of your relativePaths/ directory.

   You should wind up with a Java project that is annotated on the top project line with something along the lines of “[GitLab1 master]” indicating that Eclipse has recognized that this project is part of a git repository and is currently working in the “master” branch.

2. You will probably see a red flag on TestRelativePath.java, indicating compilation errors. Open that file and look at it. You’ll see that the errors focus on everything JUnit-related.

   • Right-click on the project name in the Package Explorer column and select Build Path-> Configure Build Path.
   • Inspect the Source tab first. You will see that Eclipse has identified the src directory as a source directory containing your source code. That means that Eclipse will compile code in and underneath that directory.
     • It does not, however, flag src/RelativePaths as a source directory. Why not?
     • Look at the top of the three Java files. (You may need to temporarily leave the Build Path dialog.) They each begin with “package RelativePaths;”. RelativePaths is a directory that serves as a Java package — the RelativePaths/ directory is actually itself part of the source code of this program, unlike src/, which is merely part of the _project structure.
       
   • Now inspect the Libraries tab in the Build Path dialog.

     Select the “Classpath” entry, and then click Add Library.... Add the JUnit4 library.

   • Apply and close the Build Path dialog. All of the error flags should disappear.

3. Run the code to see what is working.

   • TestRelativePath.java is a JUnit test. Right-click on it, select "Run as -> JUnit Test`. The tests should pass.
   • ShowRelative.java is the main program. Right-click on it, select "Run as -> Java Application`. You should be able to use this to print relative paths between any two file locations.

4. Because you have copied a lot of files into the directory since making the clone, Eclipse should be flagging multiple files as having been changed. In addition, setting up the Eclipse project will have added .project and .classpath files.

   Whenever you add new files to a project you need to tell Git to start tracking them. Luckily, after the initial setup, you generally only do this one or two files at a time. For now, though, you need to add a bunch to the tracking list. This is done by right-clicking on files and directories and selecting either “Add to Index” or “Ignore” from the Team menu.

   First, though, you need to be able to see some things. At the top of the project pane, click the button with the three vertical dots (in some Eclipse installations, this is a small triangle) to drop down a menu that includes “Filters”. Select that, and clear the entry for “.* resources”.

   Mark as ignored: The .project and .classpath files, the bin directory, if you have one (We don’t want any binary files such as class files checked in, because we would rebuild those anyway.)

   Add to the index: your src directory, and, last of all, the .gitignore file.

   (After you have done this, you might want to open the .gitignore file and tack a look at what’s in there. You can see that it records which files you have chosen to ignore. I often tweak this file by adding lines containing “*~” and “*.bak” to ignore common backup files left behind by editors.) so that common backup )

5. Right-click on your project, and from the Team menu select “Commit…”. This will open a “Git Staging” tab/window. Verify that everything looks right, type in a descriptive Commit Message, and select “Commit and Push”.

6. Return to your your GitLab project page. Refresh the project home page if necessary. Then examine the Activity page.

Now select the Repository area of your project and look at the Files, Commits, and Graph pages. You should see ample evidence of the effect of your commit.