24wi ver.

Note: this is for the Winter 2024 iteration of CSE 391. Looking for a different quarter? Please visit https://courses.cs.washington.edu/courses/cse391/.

HW4 - git (2 points)

Due Tuesday 02/06 at 1:00 pm. No late submissions accepted.

Submission: Gradescope

Specification: Spec


This assignment focuses on using Git for version control. You can do this lab from the CSE VM or from attu.

Info

This autograder is still in its early stages, so there may be residual bugs left over. Don’t hesitate to post on Ed if you have any issues with the autograder!

Info

Grading works a little bit differently for this assignment. To receive 2 points for this assignment, you only need to get 1.5 points (or more) on the Gradescope autograder. We reserve the right to change your grade if you submit a repository that is not yours.

Git is a fairly complex tool that can be used in many different ways. We will show you common ways you might use git in a course or for your own projects. But if you run into problems with Git, be aware that doing a web search for answers could lead you to a solution that refers to a different problem than the one you have. The homework page on the course website links to several resources that you may find helpful.

Task 0: Getting ready to use Git and the CSE GitLab service

  1. Log on to GitLab - All students in CSE 391 have been given access to the CSE GitLab service for this quarter. If you are a CSE major, you should log on using your CSENetID, otherwise use your UWNetID. Log on to CSE GitLab by going here: https://gitlab.cs.washington.edu/
  2. Add one or more SSH keys to your account – In order to talk to the GitLab service from your computer or attu you will want to create SSH keys on those computers and copy the public SSH key for each computer into your GitLab account.

    Caution

    You need a new SSH key for every machine. attu is a separate machine from your local machine! If you created a SSH key on your local machine for a previous course but you are working on attu, you need to log on to attu and create a new SSH key on attu.

    We suggest you do not add a password, even though the documentation says it is best practice. We suggest you accept the default location for the key and that you do not add a password, meaning you can just hit return three times when generating the key.

    Once you have created a key on your local machine, next, on GitLab, click on the down arrow next to the circle at the top right of the screen and select “Settings”. Next, select “SSH Keys” from the left-hand side of the page. Or you may go directly to the URL: https://gitlab.cs.washington.edu/-/profile/keys. On your local machine, type: cat ~/.ssh/id_rsa.pub to see your key.

    Copy and paste the key into the provided text box on GitLab. You can give it a Title like “attu” or “CSE VM” to identify which computer the key goes with. Click the green button labeled “Add Key”.

  3. Configure Git – Whether you are working on attu or the CSE VM, you will want to configure a few things before you get started with Git. This slide from lecture gives a brief summary, but basically type these things at your terminal prompt:

    • Set up your user information. Once again, if you’re a CSE Major you can use your CSE email. Otherwise, use your UW email.

      git config --global user.name "Your Name"
      git config --global user.email yourEmail@uw.edu
      
    • If you want to use an editor other than vim for commit messages, you may want to set your default editor, for example:

      git config --global core.editor emacs
      

      Tip: if you find yourself in vim by mistake, use :q (colon, the letter q, then enter) to quit.

    • You can check what you have set so far using git config –-list.

    • Note: When you push, you may encounter a message like this when pushing:

      warning: push.default is unset; its implicit value is changing in
      Git 2.0 from 'matching' to 'simple'.
      

      This new default value in Git 2.0 will be fine. You can make this warning go away by setting push.default to be the new default in Git 2.0 like this:

      git config --global push.default simple
      
  4. Log in and download the homework4.sh file – For this assignment, you will turn in a .sh file as usual, you will turn this into gradescope. Download this file to your system:

    wget https://courses.cs.washington.edu/courses/cse391/24wi/homework/hw4/homework4.sh
    

    The first task will be graded by looking at the state of the commits in your repository.

    For task two, you will follow the same format as previous homework assignments, replacing the echo command with your command.

Task 1: Create a Git repository, import and edit files

Problem 1: Find your repo on gitlab

You should have gotten an email inviting you to cse391/24wi/hw4 group on Gitlab where your repo name is just your netid (e.g., cse391/24wi/hw4/rea2000). We have created the repo for you in order for us to be able to autograde the assignment, but you can create your own private repos for your homework/projects on gitlab in the future easily by going to projects and clicking new project on gitlab. Navigate to this repo on gitlab.

Problem 2: Add initial files to the repo

After you have found the repo, the project page will show you customized instructions for adding your first files to it. The first option (“Create a new repository”) involves cloning the empty repo and adding, committing, and pushing a README file to the remote repo. The second option (“Existing folder”) is useful if you already have an existing folder of files that you want to add to the repo you just created. Here we will use the first option.

Type these commands at a terminal prompt in the directory where you would like to copy the (currently empty) repo:

git clone git@gitlab.cs.washington.edu:cse391/24wi/hw4/your_netid.git
cd your_netid
git switch -c main
touch README.md
git add README.md
git commit -m "add README"
git push -u origin main

Caution

Git should not ask you for a password when running git clone. If you are asked for a password, check that your SSH key is setup properly.

Info

git switch might not exist on older versions of Git (e.g. on vergil). In that case, instead of git switch -c main, use git checkout -b main.

After executing these commands, the directory you are in (which should be named after your project) is your “working directory” in Git terminology. Your working directory is where you will edit and create files to add and commit to your local repo. At this point if you do an ls –a in your working directory you should see the file README.md (md stands for markdown) and a .git directory that is where your local copy of the repo lives. You will not cd into the .git directory or modify files in this directory directly. Instead this directory serves as your local copy of the repository and you will interact with it via Git commands (eg. git add, git commit).

If you go to the GitLab web page for your repo, and refresh, you should see that README.md is now there since you pushed it to the remote repo.

Problem 3: Add a file to your repo

Copy the menu.txt file from the homework website into your working directory. If you are still in your working directory you can do this using:

wget https://courses.cs.washington.edu/courses/cse391/24wi/homework/hw4/menu.txt

Type git status and notice that menu.txt is shown in red and listed as an “untracked file”. Now we will change this by asking menu.txt to be tracked with:

git add menu.txt

Typing git status again will show that menu.txt is now shown in green as a new file to be committed. Let’s commit it to your local repo by typing (do NOT cut and paste!) one of the following (# indicates a comment), make sure to use the commit message “Added menu.txt”:

# Option 1: Short commit message
git commit -m "Added menu.txt"

# Option 2: Long-form commit message (opens your editor)
git commit

Finally, let’s push the changes in your local copy of the repo to the remote repo on GitLab.

git push

On GitLab, if you refresh the files, you should see that menu.txt is now there.

Run git log in your directory to see recent commit history.

📬 This question is graded by looking in your repo for a commit which adds this file and has the exact commit message “Added menu.txt”.

Problem 4: Edit a file from the repo

In your working directory, edit the file menu.txt and add exactly four lines to the file. Now issue the command git status. Issue the command git diff to see changes that appear in your working directory that have not been staged.

Use the commands we’ve learned from class to add your changes to a commit and push them to the remote repo.

📬 This question is graded by looking in your repo for a commit which modifies menu.txt by adding exactly four lines.

Problem 5: Relocate a file in the repo

We have decided we may add more menus to the repo in the future, in order to accommodate this in our repo, we want to move menu.txt to a directory called menus in our repo.

Use the appropriate commands to stage your new directory and the menu.txt file, commit, and push your changes to the remote repo.

📬 This question is graded by looking in your repo for a commit that moves menu.txt to a directory menus so the new path of menu.txt ends in menus/menu.txt.

Problem 6: Explore more!

Feel free to experiment with adding more files, making edits and other commands such as: status, diff, log, blame.

Try git help <command> for more info on these. There is nothing you need to submit for this question.

Task 2: Getting familiar with some git commands

This task will give us some more experience with common git commands and some of their most commonly used options. This task will look similar to the format we’ve used for previous homework assignments in this class. Enter your answers inside of each function in homework4.sh.

This is just a function that tells the autograder where to clone your git repository from. Put your repository URL from the address bar at the top of your browser (not “Clone with HTTPS”), which starts with https:// and does not end with .git. Alternatively, use the link from “Clone with HTTPS,” but remove the .git ending.

So, it should look something like this:

Caution

Do not remove the echo from this command!! But only for this command!

function print_link {
  # Type your answer to problem #1 below this line
  echo "https://gitlab.cs.washington.edu/cse391/24wi/hw4/name-of-your-repository"
}

For example, if Matt’s UW NetID is mxw2000 (it’s not), his function would look like

function print_link {
  # Type your answer to problem #1 below this line
  echo "https://gitlab.cs.washington.edu/cse391/24wi/hw4/mxw2000"
}

Caution

Make sure your URL exactly matches the URL for your repo (not Matt’s)!

Problem 1:

Explore the git man pages, what is the command we can use to get information about the most recent commit (and only the most recent commit!) You will need to pass a flag to one of the commands we have already used earlier in this assignment.

Problem 2:

What is the command to output the differences between the most recent commit and its grandparent? Hint: The most recent commit is referred to as HEAD by git. Likewise, a commit n commits before the most recent commit is denoted by HEAD~n.

Problem 3:

What is the command to find out who was responsible for changing each line of menu.txt and when? For this problem, the autograder will run your command in the menus/ directory. Hint: the command you’re looking for is not git log.

Task 3: Make and resolve a merge conflict

Problem 1: Go to a new branch

The first step in making a merge is to create a feature branch where you will be making a change to the repository that you don’t want to make on the main branch.

To do this, you can execute this command within your repository directory:

git checkout -b "sort-menu"

This command uses git checkout and the -b flag to create a new branch called “sort-menu” and check it out (aka move to that branch).

Problem 2: Sort the menu

Now that you’re in the branch, sort the food items in menu.txt alphabetically from A-Z (you can use commands that you have learned in previous weeks or do it manually) and then append “Happy Thanksgiving!” to the end of the sorted menu.

After you do that, execute git add menu.txt or git add . to track the changes made by sorting. Let’s commit this change to your local repo branch by typing (do NOT cut and paste!) one of the following (# indicates a comment), make sure to use the commit message “Sort menu.txt alphabetically”:

# Option 1: Short commit message
git commit -m "Sort menu.txt alphabetically"

# Option 2: Long-form commit message (opens your editor)
git commit
Lastly, push your branch to GitLab by typing the command:
git push --set-upstream origin sort-menu
📬 If you don’t push the branch the autograder won’t be able to grade your submission properly, resulting in a potential loss of points.

Problem 3: Conflicting menus

For this problem, move back to the main branch of the repository by using the git checkout command:

git checkout main
In the main branch, add “Gobble Gobble” to the end of the unsorted menu. Then use the commands we’ve learned from class to add your changes to a commit. Now that you have committed the Gobble Gobble addition to main, you can attempt merging the “sort-menu” branch with main using this command (from the main branch):
git merge sort-menu
At this point, the command line should tell you that there is a merge conflict. To fix this conflict, you first need to edit menu.txt with your text editor of choice (vim or emacs), and you should see lines that look something like this:
<<<<<< HEAD
Gobble Gobble
=======
Happy Thanksgiving!
>>>>>> sort-menu
Now all you need to do is fix this conflict by keeping one or both of the end messages and removing the <<<<<< HEAD, =======, and >>>>>> sort-menu lines. The last thing to do is save your changes to menu.txt and finish up the commit by typing git commit. Remember to keep the items in the menu other than “Gobble Gobble” and/or “Happy Thanksgiving” sorted (this will be graded).

📬 This is in part graded by looking in your repo for a commit that has the message Merge branch 'sort-menu' so don’t change the default commit message and simply save and exit the editor (e.g., Esc :wq in Vim or C-x C-s C-x C-c in emacs).