add lab2

Labs/Lab2/git-conflict/README.md

+# Git Merging (and conflicts)
+
+1. In an SSH session, run `export EDITOR=nano` so that `nano` is your default editor for the following practice.
+
+2. Clone the directory first. If you have already cloned it, `cd` into the directory and then run `git pull` to update the directory.
+
+3. Navigate (with `cd`) to `labs/git-conflict` within the semester repo.  Run `unzip repo.zip` to create a `repo` directory, which contains an `adder.py` program. (If you cannot run `unzip` correctly, try to install unzip by running `sudo apt-get install unzip`. Enter "9" for the prompt.)
+
+4. `cd` to the `repo` directory and run the program: `python3 adder.py`.
+
+5. Use `ls` and `cat` (or `nano`) to browse the file(s) in the repo. 
+
+6. Run `git branch`, making a note of what branch the HEAD is currently on (the `*` indicates the `HEAD`).  Make a note of the other branches.
+
+7. Your job is to merge the other branches into the main branch, using `git merge ????` commands.  After each merge, check what files are in the directory you're working and what they contain.
+
+**Notes:**
+
+* The first merge you do will be easiest, because it is a roll forward merge.  Each of the three branches share a common history with `main`, so `main` can just catch up with the latest commits
+* The changes on the `docs` branch are on a separate file (README.txt), so that will never conflict with the other changes
+* There will be a conflict once you've tried to merge both `args` and `func-rename`.  Resolve it like we did in class.
+
+**Conflict resolution hints:**
+
+* Use `nano` to open the file with the conflict.  The file will contain conflicting code.  Edit everything so you have the version you want, and the extra characters added by git are removed.
+* Whenever you aren't sure of the next step, run `git status` to get the hint about how to "mark resolution" or "conclude the merge"
+
+When you're all done, the `adder.py` program should look like this:
+
+```python
+import sys
+
+print("Welcome to the adder program!")
+
+def add(x, y):
+    print(f"{x} plus {y} is {x+y}")
+
+if len(sys.argv) == 3:
+    add(int(sys.argv[1]), int(sys.argv[2]))
+else:
+    print("Usage: python3 adder.py <x> <y>")
+
+print("Bye")
+```
+
+And it should be runnable like this (promt will vary):
+
+```
+PROMPT$ python3 adder.py 3 5
+Welcome to the adder program!
+3 plus 5 is 8
+Bye
+
+```

Labs/Lab2/git-pr/README.md

+# GitLab
+
+In this lab, you'll practice using git. You'll create your own repo, and push changes there.
+
+## Background
+
+A **repo** contains a bunch of commits, and usually a few branches to
+label different commits.  In order to support collaboration and
+offline work, it is common to have multiple copies of the same repo.
+For example, say there is a team of 3 people working on an open-source
+project.  There will probably be six copies of the repo: one on each
+person's laptop or virtual machine and one on each person's GitLab
+account (with one of the GitLab ones being the primary home for the
+code).
+
+Various git commands and tools can be used to syncronize the copies.
+For example, running `git push origin test` uploads the `test` branch,
+and all the associated commits, to `origin`:
+
+<img src="0.png" width=800>
+
+`origin` is an example of a **remote**, a shorthand name to use instead
+of a full URL for a repo somewhere else (like GitLab).  When you
+`clone` a repo from GitLab, you automatically get a remote called
+`origin`, but you can setup more yourself.
+
+`clone` is a one-time thing to make a new copy of a GitLab repo on
+your computer and download all the commits/branches/etc.  If new
+changes are made on the GitLab repo, you can instead run `git pull` to
+download these without creating a whole new copy of the repo.
+
+In addition to these three general git commands (**clone**, **pull**, **push**),
+GitLab has two key tools for syncing repos:
+
+* **fork**: copy somebody else's GitLab repo to a new repo (called a fork) on your account
+* **pull request**: ask somebody to bring some new code you uploaded to your fork back into the main repo
+
+Consider a concrete example of how to use all these commands.  Say you find a bug in `pandas`, fix it, and want to share the fix back.  You might do the following:
+
+1. Find the pandas repo on GitLab
+2. Clone the pandas repo to a copy on your computer
+3. Fork the pandas repo to a copy in your own GitLab account
+4. Make the change to the copy on your computer
+5. Add a remote so that you can push from your computer to your GitLab fork
+6. Do a push to upload your changes from your computer to your fork
+7. Do a pull request from your fork to the main pandas repo
+8. Somebody in charge of main repo will consider your changes, and probably (a) click a button on GitLab to incorporate your changes, or (b) give you feedback to make the code better first, in which case you go back to step 4
+
+## Step 2: SSH Keys
+
+These steps are similar to the previous lab.  There, we created SSH keys
+on your laptop, allowing you to connect laptop=>VM.  Now, we're
+creating SSH keys on your VM, allowing you to connect VM=>GitLab.
+
+Connect via SSH to your VM.
+
+Run `ssh-keygen` on your VM and repeatedly hitting `ENTER` to accept
+all the defaults (including an empty password).
+
+Run the following and **copy** the output:
+
+```
+cat ~/.ssh/id_rsa.pub
+```
+
+Select "New SSH key".
+
+Name the key "cs320-vm" (or whatever you like, really) and paste the
+contents of `id_rsa.pub` to the "Key" box.
+
+Click "Add SSH Key" to finish adding it.
+
+## Step 3: Create a Repo
+
+Create a public repo called
+"cs320-lab2". Do NOT initialize the repo by clicking on any checkbox at this step. Do NOT select "Add a README file".
+
+This should create a repo. Go to that repo. Click the **Clone** button, and then click **ssh**. Copy the commands in it. We want to run those in a new directory on your computer.  So run this in the terminal:
+
+```
+mkdir cs320-lab2
+cd cs320-lab2
+```
+
+Then paste and run `git clone ` + what you copied from GitLab.  You shouldn't be
+asked for a password (if so, double check you did the parts of step
+2+3 related to SSH correctly).  If you see "Are you sure you want to
+continue connecting?", type "yes" and ENTER.
+
+If prompted, you can configure your username/email:
+
+```
+git config --global user.name "your_gitLab_username"
+git config --global user.email "your_email"
+```
+
+Refresh the GitLab page for your repo.  You should now see the first commit.
+
+Make another change to README.md on your computer (for example, say
+"hello world"), push those changes to GitLab, then refresh the page.
+Like this (one step at a time): 
+
+```
+nano README.md # make some changes, then save
+git status
+git add README.md 
+git commit -m 'say hello'
+git push
+```
+
+Keep in mind `nano` is an in-terminal text editor so you can only use
+keyboard shortcuts (not the mouse). Do control-O to write the file.
+"^" means CONTROL, and the bottom of the screen should provide hints.
\ No newline at end of file

Labs/Lab2/git-sim/README.md

+# Git Simulator
+
+Let's start by practicing in the Git simulator <a
+href="https://tyler.caraza-harter.com/cs320/learnGitBranching/index.html"
+target="_blank">here</a>.  Try to run commands to get to the following state (if you get stuck, check the [solution here](solution.md)):
+
+<img src="1.png" width=500>
+
+Useful commands for the above problem:
+* `git commit`: make a new commit
+* `git branch bname`: create a branch named `bname`
+* `git checkout bname`: move `HEAD` to the commit referenced by the `bname`
+* `git checkout c1`: move `HEAD` to the `c1` commit
+* `git merge bname`: merge changes on the `bname` branch into the current branch
+* `git branch -D bname`: delete the branch named `bname`
+
+If you have some free time at the end of the lab, you can try out the following challenge. 
+
+Try to get to this state (no answer to check for this one, so you'll need to work for it!): 
+
+<img src="2.png" width=500>
+
+**Hint:** Start by creating commits on four branches, b1, b2, b3, and b4.
+Merge b2 into b1 and b4 into b3.  Then merge the two merge commits
+with a third merge commit.

Labs/Lab2/git-sim/solution.md

+# Solution
+
+## Steps:
+
+1. git commit
+2. git checkout c1
+3. git branch test
+4. git checkout test
+5. git commit
+5. git commit
+6. git checkout c3
+7. git checkout -b feature
+8. git commit
+9. git checkout test
+10. git merge feature
+11. git branch -D feature
+
+## Result:
+
+<img src="./1.png" width=600>