Skip to main content Link Search Menu Expand Document (external link)
DSC 180AB

đź›  Methodology Assignment 4

Before attempting this assignment, make sure to read Lesson 6. Submit this assignment to Gradescope by Thursday, November 16th at 11:59PM. Post questions with the assignment on Ed.

This assignment is loosely based on Atlassian’s tutorial on Git merge conflicts. The purpose of this assignment is to familiarize yourself with how to resolve merge conflicts, as they’re the most common type of issue you’ll run into when collaborating on code with other people.

You’ll need to complete this assignment with a partner! Your partner doesn’t need to be in your domain. If you can’t find someone to work with, you can post on Ed. Absolute worst case, you can work with someone who is not in this class, but ask Suraj before pursuing this option.

Once you have a partner, you’re ready to proceed. Choose one of you to be “Partner A”; the other will be “Partner B.” Both of you should work on the assignment together, either sitting next to each other on your computers or on a Zoom call. When Partner A is working, Partner B should be helping them with what to do, and vice versa. This is pair programming.

Step 1 – Initializing the Repository

Partner A should create a new public GitHub repository called DSC180A-Methodology-4. Click “Add a README file.” Once the repository is created, Partner A should click the “Settings” button in the menu bar at the top, then the “Collaborators” button in the menu bar on the left, and then add Partner B as a collaborator. Now both Partner A and Partner B have full access to the repository.

Step 2 – Populating the Repository with Files

Partner A should clone the repository locally. Then, they should:

  1. Edit README.md so that, underneath the line with # DSC180A-Methodology-4, there’s a single line of text with their full name.
  2. Download lec02.ipynb and place it in the repository. (Don’t change anything about the notebook. Yes, this this the notebook used for Lecture 2 in DSC 10 this quarter – the point is to simulate a real-world problem!)
  3. Now, Partner A should use git status to see a list of the files that Git thinks have been added or modified. In addition to README.md and lec02.ipynb, Git may also think that .DS_Store and/or .ipynb_checkpoints/ were added. We don’t want these junk files to be tracked by Git, since they don’t contribute any meaningful content. So, do one of the following:
    1. Create a file named .gitignore with two lines: .DS_Store as the first line and .ipynb_checkpoints/ as the second line. Then, use git status to verify that the only files that Git is tracking are README.md, lec02.ipynb, and .gitignore, and then use git add ..
    2. Use git add README.md and git add lec02.ipynb so that the other junk files aren’t added.
  4. After using git add in one of the two ways mentioned above, Partner A should git commit and git push their changes. The repository at github.com/<Partner A’s username>/DSC180A-Methodology-4 should now have two files – a README.md with # DSC180A-Methodology-4 as the first line and Partner A’s full name as the second line, and a lec02.ipynb. (It may also have a third file, .gitignore – this is fine.)
  5. Finally, Partner A should run git config pull.rebase false. This sets up the repository so that anytime changes are pulled, they are merged in.

Step 3 – Making Changes

Now, Partner B should clone the repository locally. Then, they should:

  1. Edit README.md to include Partner B’s full name instead of Partner A’s full name.
  2. Open lec02.ipynb locally. Search for “PEMDAS”. Edit the two cells underneath the “Python uses the typical order of operations – PEMDAS (BEDMAS? 🛏️)” heading to match what’s shown below. Don’t run the cells.
  3. git add, git commit, and git push their changes.
  4. Finally, run git config pull.rebase false.

Step 4 – A Wild Merge Conflict Appears!

This step is where the bulk of the work is.

Partner A should not pull the latest changes in the repository at this point! Instead, they should:

  1. Edit README.md to include another line below their name that contains their UCSD email.
  2. Open lec02.ipynb locally. Search for “PEMDAS”. Edit the two cells underneath the “Python uses the typical order of operations – PEMDAS (BEDMAS? 🛏️)” heading to match what’s shown below. Don’t run the cells.
  3. git add, git commit, and try to git push their changes. After running git push, Partner A will see something like this in their Terminal:
     error: failed to push some refs to 'https://github.com/surajrampure/DSC180A-Methodology-4.git'
 hint: Updates were rejected because the tip of your current branch is behind
 hint: its remote counterpart. Integrate the remote changes (e.g.
 hint: 'git pull ...') before pushing again.
 hint: See the 'Note about fast-forwards' in 'git push --help' for details.

    Partner A should then try to run git pull; they’ll see the output below.

     Auto-merging README.md
 CONFLICT (content): Merge conflict in README.md
 Auto-merging lec02.ipynb
 CONFLICT (content): Merge conflict in lec02.ipynb
 Automatic merge failed; fix conflicts and then commit the result.

    Now, Partner A needs to fix the merge conflicts!

  4. Partner A should open README.md. It’ll look something like the following, just with different names and a different commit hash. (If it doesn’t look like this, run git config pull.rebase false and then git pull again.)
    # DSC180A-Methodology-4
<<<<<<< HEAD
Suraj Rampure
srampure@ucsd.edu
=======
Dilraj Gill
>>>>>>> 4cda707262d5798f4e1b423419220a924c79179a

    From Atlassian’s merge conflicts tutorial:

    Think of these new lines as “conflict dividers”. The ======= line is the “center” of the conflict. All the content between the center and the «««< HEAD line is content that exists in the current branch main which the HEAD ref is pointing to. Alternatively all content between the center and »»»> new_branch_to_merge_later is content that is present in our merging branch.

    Partner A needs to edit README.md so that it doesn’t contain <<<<<<< HEAD, =======, or >>>>>>> 4cda707262d5798f4e1b423419220a924c79179a. They should edit it so that README.md only contains two lines: one with # DSC180A-Methodology-4 and another with the names of both partners separated with an “and” (e.g. Suraj Rampure and Dilraj Gill), no emails. If you’re using VSCode, it may automatically detect that these lines were added by Git and let you choose which versions to keep.

  5. Partner A now needs to fix the merge conflict in lec02.ipynb. This will be more difficult, because the inclusion of <<<<<<< HEAD, =======, >>>>>>> 4cda707262d5798f4e1b423419220a924c79179a prevent lec02.ipynb from being a valid notebook. If you try to open it, you’ll see the following in your Terminal:
     [W 14:30:34.302 NotebookApp] 400 GET /api/contents/lec02.ipynb?type=notebook&_=1699558234145 (::1): Unreadable Notebook: /Users/surajrampure/Desktop/DSC180A-Methodology-4/lec02.ipynb NotJSONError('Notebook does not appear to be JSON: \'{\\n "cells": [\\n  {\\n   "cell_type": "c...')

    The solution is to rename lec02.ipynb to lec02.json, and then open lec02.json in a text editor. (Notebooks are stored as JSON files.) Search for <<< HEAD to see the part of the notebook with the merge conflicts. If you opened the file in VSCode, you might see something like:

    Partner A should edit the source code so that, once lec02.json is renamed to lec02.ipynb, the affected cells look exactly like the following:

    This is truly a merge of the work done by both Partner A (who added the comments) and Partner B (who changed the expressions).

    This may take a little bit of trial and error to get right. Take a look at the JSON representations of existing cells for an idea of what to do, and make sure that your edits to lec02.json make it a valid JSON file.

  6. Now, Partner A should git add, git commit, and git push their changes. Merge conflict resolved – that wasn’t so scary!

Step 5 – Logging and Submitting

Now, Partner B should git pull the changes locally.

  1. To prove to us that you followed all of the above steps, you’ll need to submit to us your Git “log”. To do so, run the command git log -p --cc >> log.txt. This will create a log.txt that shows us the Git history of your repository, including the fact that you resolved your merge conflict according to the rules we set up above.
  2. Partner B should now git add, git commit, and git push log.txt.
  3. Finally, Partner B should submit the Git repository <Partner A's username>/DSC180A-Methodology-4 to Gradescope. (As long as Partner A correctly added Partner B as a collaborator, Partner B will be able to submit, even though the repository is “owned” by Partner A).

After a few minutes, you should be able to confirm that you received a full score!

Remember to enroll in the DSC 180B discussion section that corresponds to your DSC 180A discussion section. You cannot change domains at this point!