add final lab 3 files

AUTHORS.md

+# Authors
+
+* Eivind Jahren, UiB (original cellular automaton code)
+* Anya Helene Bagge, UiB  (graphics, maintenance)
+* Lars Jaffke, UiB (Langton's Ant)
+* *you*, UiB (the rest!)
+ 
\ No newline at end of file

LAB-3.md

-# Lab 3: Langton's Ant og Litt Mer Avansert Git
+# Lab 3: Langton's Ant & Git Merge Requests
 
 
 ## Læringsmål
 
 * Kunne håndtere *rejected* feil fra *Git push på* egenhånd.
-* Kjenne til Git-konseptene *upstream* og *remote* og vanlig litt avansert bruk av disse.
+* Kjenne til vanlig Git arbeidsflyt og kunne bruke *merge request*.
 * Få mer erfaring med grid-datastruktur og vanlig programmering
 
+*(Resten av oppgaven er på engelsk. Siden det er en del bakgrunnstekst også, er seksjonene med ting du skal gjøre merket med “(todo!)”.)*
 
 ## Part I: Git
-### Step 1.0: More Git Background
-Git is a [distributed version control system](https://en.wikipedia.org/wiki/Distributed_version_control):
-* A [version control system](https://en.wikipedia.org/wiki/Version_control) stores all previously committed changes to a project. (This lets you undo mistakes, maintain multiple versions of the same piece of software at the same time, and easily track the history of changes when you're trying to find out why something went wrong.)
-* Modern version control systems are collaborative, and let multiple people work independently on their own copy of the files, before the changes are integrated / synchronised. Since all the changes are recorded in the history it's easy for the version control system to see what each developer has done, and merge changes from multiple developers more or less automatically. Typically, this synchronisation happens when a developer *pulls* from or *pushes* to the server (sometimes called *update* and *check in*). (In really old systems, there was little or no support for multiple developers, and you might be required to *lock* the files you were editing, so that no one else could modify them at the same time. If you then went on vacation without unlocking, your co-workers would be very upset.)
-* A *distributed* version control system like Git also supports decentralised collaboration: there isn't really a central server that everyone synchronises with – instead each developer has a complete *clone* of the entire project, and developers can exchange their commits peer-to-peer, without any server. For practical reasons (e.g., backups and easier interaction), we typically want a server anyway and this is the role of our GitLab-installation at https://retting.ii.uib.no/. Your local clone of your INF101 labs are just as good and complete as those on the server, but the server also does backups, lets your teachers look at and help you with your code, has a nice web interface and does automatic integration testing whenever you push to it.
 
-Collaboration and distribution has two consequences that we will deal with now:
-* Someone else can have made changes while you were working, and these changes must be integrated with yours. (Step 1.1 below, and [Lab 1, oppg. 7](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab1/blob/master/README.md#oppgave-7-rot-med-merge).)
-* We change change what we consider to be the “server” or even have multiple ones. (Step 1.3 below.)
+(Do Lab 2 first!)
 
-### 1.0. Always *pull* before *push*
-As seen in [Lab 1, oppg 4](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab1/blob/master/README.md#oppgave-4-pushe-til-gitlab-rettingiiuibno) you should check the response you get whenever you *push*, because it can actually go wrong.
-
-If you see the message *rejected – non-fast-forward*, someone else has made and pushed changes before you. This could be someone yourself, if you're using multiple computers or if you've made multiple copies of your Git files on your computer – but in real life it's often another developer on the same project (less likely for INF101 students, but sometimes Anya or someone else will push to your repository on retting.ii.uib.no.).
-
-So, if you go and make some changes to your *Lab 2* solution, then select *Team → Commit...*, fill in the commit form or staging view form and hit *Commit and Push*...
-
-![](img/git-staging.png)
-
-...you should see a message like this (but with a different repository name, of course):
-
-![](img/push-rejected.png)
-
-* Go and do this now, with your `inf101.v18.lab2` project. If you don't have any changes to commit or push, just do a tiny change to any of your java files (insert an extra line, for example).
-
-* You get the *rejected* message because the server's copy has changes that you haven't seen (mainly just a few corrections in the exercise text). It's your responsibility to integrate those changes from the server into your local repository (this is called *merging*), before you can push the combined changes back to the server.
-
-* First, right-click on your Lab 2 project, and select *Team → Pull* from the menu. You should get an OK message similar to the one below (possibly after entering your password again):
-
-![](img/pull-result.png)
-
-* The list will include all the changes that have been integrated into your project. In your case it should be the top three commits from the [Lab 2 commits log](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab2/commits/master).
-
-* If the message says *Failed*, some of our changes are in conflict with some of your changes (unlikely unless you've changed the text of the README.md file). You'll have to resolve this as seen in [Lab 1](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab1/blob/master/README.md#oppgave-7-rot-med-merge).
-
-If you're working on the command line, the message will look like this:
-```
-To https://retting.ii.uib.no/anya/inf101.v18.lab2.git
- ! [rejected]        master -> master (fetch first)
-error: failed to push some refs to 'https://retting.ii.uib.no/anya/inf101.v18.lab2.git'
-hint: Updates were rejected because the remote contains work that you do
-hint: not have locally. This is usually caused by another repository pushing
-hint: to the same ref. You may want to first integrate the remote changes
-hint: (e.g., 'git pull ...') before pushing again.
-hint: See the 'Note about fast-forwards' in 'git push --help' for details.
-```
-and it's solved by running `git pull`, and then `git push` again.
-
-**General rule:** when you're working with Git, you will normally have to do *pull* before you can do *push*. So, your sequence of steps should be:
-* *Commit* your work (remember to include all relevant files and a nice commit message).
-* *Pull* to see if anyone else has made any changes.
-* *Push* to send the changes to the server.
-
-If you're mostly working alone (as in INF101), you can normally skip the *pull* step, and then just do it if your push is rejected (this will fix 95% of push problems; ask for help with the rest).
-
-### 1.1. Checking status of edits and commits
-If you're wondering if all your changes have been committed and pushed, you can see this in the Eclipse package explorer.
-
-![](img/commits.png)
-Here, “↑1” indicates that you have made one commit that hasn't been pushed yet. You may also have “↓N” (much less likely), which means that you have fetched N commits from the server, but those haven't been merged yet.
-
-A “>” indicates that a file has been edited but not committed yet (or that a folder (transitively) contains such a file):
-![](img/edited-files.png)
- 
-If you have added a file (made a new class, for instance), it will have a small question mark in the corner of its icon:
-
-![](img/new-file.png)
-
-You should add such files to Git, either with *Team → Add to index...* or in the commit dialog – except if it's an irrelevant file for some reason (not really part of the project, or it's generated automatically), in which case you should do *Team → Ignore* on it. As you see on `SeedsAutomaton.java`, files that are in Git have a little yellow cylinder in the corner of their icon.
-
-On the command line, you can get the same information with `git status`.
+[Go to Part I](LAB-3_I_GIT.md)
 
 ## Part II: Langton's Ant
-This week's Lab-exercise deals with another type of cellular automata, [Langton's Ant](https://en.wikipedia.org/wiki/Langton's_ant). This automaton was conceptualized in 1986 by Chris Langton and proven to be [Turing-complete](https://en.wikipedia.org/wiki/Universal_Turing_machine) 2000. In other words, any algorithm can be simulated by Langton's Ant.
-
-The idea of the automaton is simple: An ant moves across the grid formed by the cells of the automaton and each cell has one of n states (or colors). The automaton is equipped with a set of rules, telling for each color i = 1,...,n whether the ant should turn left or right when stepping on a cell with color i. After the ant left the cell, the color is shifted in a cyclic fashion, i.e. a cell with color i is set to color (i+1) mod n.
-
-The standard Langton's Ant has two states, say black and white and the following rules:
-
-- White: Turn right.
-- Black: Turn left.
-
-An example execution of a few steps looks like this: 
-
-<p><a href="https://commons.wikimedia.org/wiki/File:LangtonsAntAnimated.gif#/media/File:LangtonsAntAnimated.gif"><img src="https://upload.wikimedia.org/wikipedia/commons/0/09/LangtonsAntAnimated.gif" alt="LangtonsAntAnimated.gif" height="353" width="353"></a><br>By <a href="//commons.wikimedia.org/wiki/User:Krwawobrody" title="User:Krwawobrody">Krwawobrody</a> - <span class="int-own-work" lang="en">Own work</span>, Public Domain, <a href="https://commons.wikimedia.org/w/index.php?curid=2041023">Link</a></p>
-
-The goal of this exercise is to implement a generelization of Langton's Ant to an (arbitrary) number of colors. In particular, a rule for a Langton's Ant can be encoded as a string of L's and R's in the following way. As an example, the rule 'LLRRRL' means that the ant should move left when encountering color 1, 2 or 6 and right when encountering color 3, 4 or 5.
-
-# Step 2.0
-Get the stuff from git
-
-# Step 2.1 Overview of the code
-The code in this exercise is based on the code of Lab 2 with the following changes/additions.
-
-- *Cellstate* is not an enum anymore but a class with a single integer value, indicating the color of the cell. The constants ALIVE, DYING and DEAD are there to ensure that the code of the old exercises still works.
-
-- *Direction* is an enum holding the values NORTH, EAST, SOUTH, WEST which is used to determine the direction the ant is facing in the grid.
-
-- *Ant* is a class that captures the position in integer (x, y) coordinates as well as the direction it is facing.
-
-- *LangtonsAnt* is a stub of a class that contains most of the logic. As before, it implements the *ICellAutomaton* interface and all logic should be implemented in the corresponding methods.
-
-# Step 2.2 Complete the ant
-In the *Ant* class, the implementations of the *turnLeft()* and *turnRight()* methods are missing. This should be done as follows. Consider *turnLeft()* (*turnRight()* works symmetrically) and suppose the ant is in position (x, y) and faces NORTH. Then a left turn means
-
-- Decreasing the ant's *x*-value by 1.
-- Making the ant face *WEST*.
-
-Analogous rules have to be devised for the other cases and implemented accordingly.
-
-# Step 2.3 Complete the implementation of LangtonsAnt
-blablabla. Throughout the following, when referring to *color i*, we mean a *CellState* object with value i.
-
-## Step 2.3.1 Check the input rule
-The *LangtonsAnt* class contains a method to verify whether a given input rule is valid or not. A rule (given as a string) is invalid if one of the following holds.
-
-- The length of the string exceeds the value of the constant MAX RULE LENGTH.
-
-- The string contains characters other than 'L' and 'R'.
-
-## Step 2.3.2 Implement *initializeGeneration()*
-Initialize the first generation of the automaton by doing the following.
-
-- Give all fields color 0.
-
-- Initialize an ant that sits in the middle of the grid, facing NORTH.
-
-- Initialize the *seenState* field to color 0.
-
-## Step 2.3.3 Implement *stepAutomaton()*
-In the automaton's step method, the ant moves according to the previously read color (stored in the field *seenState*) and shifts the color of the field it is leaving. 
-
-Note that a new *Ant* object *nextAnt* has been initialized and that everything that concerns the future position of the ant in the grid have to be executed on that object.
-
-The followig things need to be done.
-
-- Fill in the calls of *turnLeft()* and *turnRight()* in the corresponding cases.
-
-- Check if the calculated position is a valid one (i.e. the ant is not thrown off the grid) and if not, reset the position in a way of your choosing.
-
-- Update the color (/state) of the field the ant is *leaving* (note that this concerns the value of the *ant* field, not the *nextAnt* variable). The next color should be (seenState.getValue() + 1) mod rule.length
-
-- Update the *seenState* field, i.e. get the color of the next cell the ant is moving to and store it.
-
-- Move the ant to the new position in the grid, using the *nextAnt* field.
-
-- Update the *ant* field variable by setting it to *nextAnt*
-
-## Step 2.3.4 Have fun!
-Replace the *ICellAutomaton* object *ca* in the *Main* with a *LangtonsAnt* object with a rule of your choosing and watch the ant draw patterns.
-
 
-## Sample output
-Multi-color Langton's Ant pattern `"RRLLLRLLLRRR"`. [See more examples at WikiPedia.](https://en.wikipedia.org/wiki/Langton's_ant#Extension_to_multiple_ants) 
+(Do Lab 2 and Part I first!)
 
-<img src="img/RRLLLRLLLRRR-1.png" width="300" alt="Ant Screenshot title="After a few minutes" />
-&nbsp;
-<img src="img/RRLLLRLLLRRR-2.png" width="300" alt="Ant Screenshot title="After around ~2 hours" />
-&nbsp;
-<img src="img/RRLLLRLLLRRR-3.png" width="300" alt="Ant Screenshot title="Running overnight / ~10 hours" />
+[Go to Part II](LAB-3_II_ANT.md)

LAB-3_II_ANT.md

+# Lab 3 Part II
+
+[Lab Overview](LAB-3.md)
+
+# Part I: Git
+
+[Go to Part I](LAB-3_I_GIT.md)
+
+# Part II: Langton's Ant
+**You must complete [Part I](LAB-3_I_GIT.md) before doing this part!**
+
+This week's Lab-exercise deals with another type of cellular automata, [Langton's Ant](https://en.wikipedia.org/wiki/Langton's_ant). This automaton was conceptualized in 1986 by Chris Langton and proven to be [Turing-complete](https://en.wikipedia.org/wiki/Universal_Turing_machine) 2000. In other words, any algorithm can be simulated by Langton's Ant.
+
+The idea of the automaton is simple: An ant moves across the grid formed by the cells of the automaton and each cell has one of *n* states (or colors). The automaton is equipped with a set of rules, telling for each color *i* = 1,...,*n* whether the ant should turn left or right when stepping on a cell with color *i*. After the ant left the cell, the color is shifted in a cyclic fashion, i.e. a cell with color *i* is set to color (*i*+1) mod *n*.
+
+The standard Langton's Ant has two states, say black and white and the following rules:
+
+- White: Turn right.
+- Black: Turn left.
+
+An example execution of a few steps looks like this: 
+
+<p><a href="https://commons.wikimedia.org/wiki/File:LangtonsAntAnimated.gif#/media/File:LangtonsAntAnimated.gif"><img src="https://upload.wikimedia.org/wikipedia/commons/0/09/LangtonsAntAnimated.gif" alt="LangtonsAntAnimated.gif" height="353" width="353"></a><br>By <a href="//commons.wikimedia.org/wiki/User:Krwawobrody" title="User:Krwawobrody">Krwawobrody</a> - <span class="int-own-work" lang="en">Own work</span>, Public Domain, <a href="https://commons.wikimedia.org/w/index.php?curid=2041023">Link</a></p>
+
+The goal of this exercise is to implement a generalisation of Langton's Ant to an (arbitrary) number of colors. In particular, a rule for a Langton's Ant can be encoded as a string of L's and R's in the following way. As an example, the rule 'LLRRRL' means that the ant should move left when encountering color 1, 2 or 6 and right when encountering color 3, 4 or 5.
+
+## 2.0
+If you have successfully completed [Part I](LAB-3_I_GIT.md), you should find your Lab 3 project at
+```
+https://retting.ii.uib.no/USERNAME/inf101.v18.lab3.git
+```
+
+* Clone it / import it into Eclipse (or your preferred IDE)
+* See previous labs or [Hvordan hente og levere oppgaver](https://retting.ii.uib.no/inf101/inf101.v18/wikis/hente-levere-oppgaver) for help
+
+## 2.1 Overview of the code
+The code in this exercise is based on the code of Lab 2 with the following changes/additions.
+
+- *Cellstate* is not an `enum` anymore but a class with a single integer value, indicating the color of the cell. The constants ALIVE, DYING and DEAD are there to ensure that the code of the old exercises still works.
+
+- *Direction* is an `enum` holding the values `NORTH`, `EAST`, `SOUTH`, `WEST` which is used to determine the direction the ant is facing in the grid.
+
+- *Ant* is a class that captures the position in integer (x, y) coordinates as well as the direction it is facing.
+
+- *LangtonsAnt* is a stub of a class that contains most of the logic. As before, it implements the *ICellAutomaton* interface and all logic should be implemented in the corresponding methods.
+
+## 2.2 Complete the ant *(todo!)*
+In the *Ant* class, the implementations of the *turnLeft()* and *turnRight()* methods are missing. This should be done as follows. Consider *turnLeft()* (*turnRight()* works symmetrically) and suppose the ant is in position (x, y) and faces NORTH. Then a left turn means
+
+- Decreasing the ant's *x*-value by 1.
+- Making the ant face *WEST*.
+
+Analogous rules have to be devised for the other cases and implemented accordingly.
+
+## 2.3 Complete the implementation of LangtonsAnt
+Throughout the following, when referring to *color i*, we mean a *CellState* object with value i.
+
+### 2.3.1 Check the input rule
+The *LangtonsAnt* class contains a method to verify whether a given input rule is valid or not. A rule (given as a string) is invalid if one of the following holds.
+
+- The length of the string exceeds the value of the constant `MAX_RULE_LENGTH`.
+
+- The string contains characters other than 'L' and 'R'.
+
+### 2.3.2 Implement *initializeGeneration()* *(todo!)*
+Initialize the first generation of the automaton by doing the following.
+
+- Give all fields color 0.
+
+- Initialize an ant that sits in the middle of the grid, facing NORTH.
+
+- Initialize the *seenState* field to color 0.
+
+### 2.3.3 Implement *stepAutomaton()* *(todo!)*
+In the automaton's step method, the ant moves according to the previously read color (stored in the field *seenState*) and shifts the color of the field it is leaving. 
+
+Note that a new *Ant* object *nextAnt* has been initialized and that everything that concerns the future position of the ant in the grid have to be executed on that object.
+
+The following things need to be done.
+
+- Fill in the calls of *turnLeft()* and *turnRight()* in the corresponding cases.
+
+- Check if the calculated position is a valid one (i.e. the ant is not thrown off the grid) and if not, reset the position in a way of your choosing.
+
+- Update the color (/state) of the field the ant is *leaving* (note that this concerns the value of the *ant* field, not the *nextAnt* variable). The next color should be `(seenState.getValue() + 1) % rule.length`
+
+- Update the *seenState* field, i.e. get the color of the next cell the ant is moving to and store it.
+
+- Move the ant to the new position in the grid, using the *nextAnt* field.
+
+- Update the *ant* field variable by setting it to *nextAnt*
+
+### 2.3.4 Have fun! *(todo!)*
+Replace the *ICellAutomaton* object *ca* in the *Main* with a *LangtonsAnt* object with a rule of your choosing and watch the ant draw patterns.
+
+* If you'd like it do run faster, you can modify `inf101.v18.cell.gui.CellAutomataGUI`. Line 72 makes the automaton do one step every 1/20 second: `timer = new javax.swing.Timer(1000/20, this);` – you can set the timer delay to, e.g., `1000/60`, or `10` (ten milliseconds).
+
+## 2.4 Have more fun! *(todo!)*
+
+There's a lot of other things you can do with cellular automata, including further extensions of Langton's Ant.
+
+* [Turmites](https://en.wikipedia.org/wiki/Turmite) extend the ant with state, and should be possible to implement with a modification to the `Ant` class.
+* There's also [Langton's Loops](https://en.wikipedia.org/wiki/Langton%27s_loops)
+* [Paterson's worms](https://en.wikipedia.org/wiki/Paterson%27s_worms) is another automaton, but uses a triangular grid (doesn't work so well with our framework).
+* There are standard rules for [Elementry cellular automata](https://en.wikipedia.org/wiki/Elementary_cellular_automaton), including the one seen on the sea snail shell in Lab 2. See the [WikiPedia page on Cellular Automata](https://en.wikipedia.org/wiki/Cellular_automaton) for more inspiration.
+* You can also try to simulate simple physical phenomena, such as fire spreading or snow fall. For example:
+  * A snow flake (an `ALIVE` cell) will move one step down per iteration if the cell below is free (e.g., if the cell below is `DEAD`, it becomes `ALIVE` and the current cell becomes `DEAD`). For this case, the order in which you process the grid in `stepAutomaton()` becomes important (you should start at the bottom and go up).
+  * A fire would need multiple states; e.g., `WATER`, `WOOD`, `IGNITING`, `BURNING`, `BURNT` and then rules to move between them.
+  * Even simple liquid flow can be simulated with automata or something close to it (e.g., use the CellState with integers to keep track of the amount of water in each square, and build rules around pressure and momentum) – though it can require a bit of physics and math.
+
+
+
+## Sample output
+Multi-color Langton's Ant pattern `"RRLLLRLLLRRR"`. [See more examples at WikiPedia.](https://en.wikipedia.org/wiki/Langton's_ant#Extension_to_multiple_ants) 
+
+<img src="img/RRLLLRLLLRRR-1.png" width="300" alt="Ant Screenshot title="After a few minutes" />
+&nbsp;
+<img src="img/RRLLLRLLLRRR-2.png" width="300" alt="Ant Screenshot title="After around ~2 hours" />
+&nbsp;
+<img src="img/RRLLLRLLLRRR-3.png" width="300" alt="Ant Screenshot title="Running overnight / ~10 hours" />

LAB-3_I_GIT.md

+# Lab 3 Part I
+
+[Lab Overview](LAB-3.md)
+
+## Part I: Git
+### 1.0. More Git Background
+Git is a [distributed version control system](https://en.wikipedia.org/wiki/Distributed_version_control):
+* A [version control system](https://en.wikipedia.org/wiki/Version_control) stores all previously committed changes to a project. (This lets you undo mistakes, maintain multiple versions of the same piece of software at the same time, and easily track the history of changes when you're trying to find out why something went wrong.)
+* Modern version control systems are collaborative, and let multiple people work independently on their own copy of the files, before the changes are integrated / synchronised. Since all the changes are recorded in the history it's easy for the version control system to see what each developer has done, and merge changes from multiple developers more or less automatically. Typically, this synchronisation happens when a developer *pulls* from or *pushes* to the server (sometimes called *update* and *check in*). (In [really](https://en.wikipedia.org/wiki/Source_Code_Control_System) [old](https://en.wikipedia.org/wiki/Revision_Control_System) systems, there was little or no support for multiple developers, and you might be required to *lock* the files you were editing, so that no one else could modify them at the same time. If you then went on vacation without unlocking, your co-workers would be very upset.)
+* A *distributed* version control system like Git also supports decentralised collaboration: there isn't really a central server that everyone synchronises with – instead each developer has a complete *clone* of the entire project, and developers can exchange their commits peer-to-peer, without any server. For practical reasons (e.g., backups and easier interaction), we typically want a server anyway and this is the role of our GitLab-installation at https://retting.ii.uib.no/. Your local clone of your INF101 labs are just as good and complete as those on the server, but the server also does backups, lets your teachers look at and help you with your code, has a nice web interface and does automatic integration testing whenever you push to it.
+
+Collaboration and distribution has two consequences that we will deal with now:
+* Someone else can have made changes while you were working, and these changes must be integrated with yours. (Step 1.1 below, and [Lab 1, oppg. 7](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab1/blob/master/README.md#oppgave-7-rot-med-merge).)
+* We change change what we consider to be the “server” (upstream) or even have multiple ones. (Step 1.3 below.)
+
+### 1.1. Always *pull* before *push* *(todo!)*
+As seen in [Lab 1, oppg 4](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab1/blob/master/README.md#oppgave-4-pushe-til-gitlab-rettingiiuibno) you should check the response you get whenever you *push*, because it can actually go wrong.
+
+If you see the message *rejected – non-fast-forward*, someone else has made and pushed changes before you. This could be someone yourself, if you're using multiple computers or if you've made multiple copies of your Git files on your computer – but in real life it's often another developer on the same project (less likely for INF101 students, but sometimes Anya or someone else will push to your repository on retting.ii.uib.no.).
+
+So, if you go and make some changes to your *Lab 2* solution, then select *Team → Commit...*, fill in the commit form or staging view form and hit *Commit and Push*...
+
+![](img/git-staging.png)
+
+...you should see a message like this (but with a different repository name, of course):
+
+![](img/push-rejected.png)
+
+* **Go and do this now**, with your `inf101.v18.lab2` project. If you don't have any changes to commit or push, just do a tiny change to any of your java files (insert an extra line, for example).
+
+* You get the *rejected* message because the server's copy has changes that you haven't seen (mainly just a few corrections in the exercise text). It's your responsibility to integrate those changes from the server into your local repository (this is called *merging*), before you can push the combined changes back to the server.
+
+* First, right-click on your Lab 2 project, and select *Team → Pull* from the menu. You should get an OK message similar to the one below (possibly after entering your password again):
+
+![](img/pull-result.png)
+
+* The list will include all the changes that have been integrated into your project. In your case it should be the top three commits from the [Lab 2 commits log](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab2/commits/master).
+
+* If the message says *Failed*, some of our changes are in conflict with some of your changes (unlikely unless you've changed the text of the README.md file). You'll have to resolve this as seen in [Lab 1](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab1/blob/master/README.md#oppgave-7-rot-med-merge).
+
+If you're working on the command line, the message will look like this:
+```
+To https://retting.ii.uib.no/anya/inf101.v18.lab2.git
+ ! [rejected]        master -> master (fetch first)
+error: failed to push some refs to 'https://retting.ii.uib.no/anya/inf101.v18.lab2.git'
+hint: Updates were rejected because the remote contains work that you do
+hint: not have locally. This is usually caused by another repository pushing
+hint: to the same ref. You may want to first integrate the remote changes
+hint: (e.g., 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+```
+and it's solved by running `git pull`, and then `git push` again.
+
+**General rule:** when you're working with Git, you will normally have to do *pull* before you can do *push*. So, your sequence of steps should be:
+* *Commit* your work (remember to include all relevant files and a nice commit message).
+* *Pull* to see if anyone else has made any changes.
+* *Push* to send the changes to the server.
+
+If you're mostly working alone (as in INF101), you can normally skip the *pull* step, and then just do it if your push is rejected (this will fix 95% of push problems; ask for help with the rest).
+
+### 1.2. Checking status of edits and commits
+If you're wondering if all your changes have been committed and pushed, you can see this in the Eclipse package explorer.
+
+![](img/commits.png)
+
+Here, “↑1” indicates that you have made one commit that hasn't been pushed yet. You may also have “↓N” (much less likely), which means that you have fetched N commits from the server, but those haven't been merged yet.
+
+A “>” indicates that a file has been edited but not committed yet (or that a folder (transitively) contains such a file):
+
+![](img/edited-files.png)
+ 
+If you have added a file (made a new class, for instance), it will have a small question mark in the corner of its icon:
+
+![](img/new-file.png)
+
+You should add such files to Git, either with *Team → Add to index...* or in the commit dialog – except if it's an irrelevant file for some reason (not really part of the project, or it's generated automatically), in which case you should do *Team → Ignore* on it. As you see on `SeedsAutomaton.java`, files that are in Git have a little yellow cylinder in the corner of their icon.
+
+On the command line, you can get the same information with `git status`.
+
+### 1.3. Merge Requests and Forks
+#### Background
+A very common situation in [online collaborative software development](https://en.wikipedia.org/wiki/Open-source_software_development) is doing minor (or even major) work on a project that isn't owned by you and where you might not be (or want to be) an official part of the development team. For instance, if you're contributing a bugfix or have implemented an extra feature for an open source project (this can be both a good way to learn, and a good way to develop your CV). You might also be working on a project that has a slightly more formalised workflow, where changes should be reviewed by the other developers before they are accepted into the project. This is the sort of situation distributed version control systems like Git are made for – Git in particular was created for the development of the [Linux kernel](https://en.wikipedia.org/wiki/Linux_kernel), which has more than 12000 contributors and a somewhat decentralised [development process](https://en.wikipedia.org/wiki/Linux_kernel#Development).
+
+The [workflow](https://retting.ii.uib.no/help/workflow/forking_workflow.md) is as follows (you don't have to do any of this now; most of the relevant bits have been done automatically):
+* You want to contribute to a project, and create a fork of the project ([retting.ii.uib.no](https://retting.ii.uib.no) supports this for projects hosted here; but all the major open hosting services like [GitHub.com](https://github.com), [GitLab.com](https://gitlab.com) and [BitBucket.org](https://bitbucket.org) all support forking). This is your own personal copy of the project which you can develop and edit without interfering with other developers. This is also how all your INF101 exercises are set up – they are forks of the main exercise repository, so students don't interfere with each other.
+* You continue development until you have changes you want integrated into the *upstream* (the project you forked from).
+* You use the hosting service ([GitLab at retting.ii.uib.no](https://retting.ii.uib.no) in our case) to send a *merge request* (also called a *pull request*) to the upstream. The system will look at all changes you have done, and all changes done to the main repository (the “upstream”), and try and see if they still fit together (if they don't, you may have to manually merge them, otherwise Git will merge automatically). The merge request is handled a bit like a bug report; the upstream developers will be alerted and can discuss the requests in the comment section – perhaps asking you questions or tell you to fix stuff they don't like.
+* If your merge request is accepted, the upstream developers will *merge* it into the upstream project, and your changes will become part of the upstream repository (i.e., the commits you made to your repository will also be part of the history of the upstream repository). 
+* You might now delete your fork, if you don't intend to do further development, or you may want to merge the upstream (if they had other changes) back into your own fork and continue working on it.  
+  
+#### Our Situation
+[Part II](LAB-3_II_ANT.md) of this exercise (the Java programming bits) is based on the same cellular automata framework used in [Lab 2](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab2/blob/master/README.md), with a few changes. Also, you will (hopefully) have done some changes to your own fork of Lab 2, such as fixing the `MyGrid` implementation. If you haven't, you should do so now – otherwise you won't be able to finish Lab 3.
+
+This situation is similar to the fork/merge workflow commonly used with Git: there's an upstream (the originally handed-out Lab 2 code from `/inf101.v18.oppgaver/inf101.v18.lab2`), which has been changed (into the Lab 3 hand-out from `/inf101.v18.oppgaver/inf101.v18.lab3`) – while you have been modifying your fork of Lab 2 (fixing `MyGrid` and implementing Brian's Brain). Before you can start implementing Lab 3, you must *merge* your Lab 2 solution (`/USERNAME/inf101.v18.lab2`) into your Lab 3 code (`/USERNAME/inf101.v18.lab3`) – both of them are based on the same original upstream repository, so you can handle this by sending yourself a *merge request*. (It's not exactly the same situation as above, since you're not actually merging with the upstream, but only with another fork of the upstream – but the technique is the same, and very useful in a collaborative setting.) 
+
+#### Your Task *(todo!)*
+
+(See below for step-by-step screenshots.)
+
+* First – finish [Lab 2](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab2/blob/master/README.md). You'll need at least a correctly working `MyGrid`.
+
+* Commit and push your Lab 2 solution (see also step 1.2 of this Lab).
+
+* Go to the project page for *Lab 2* at `https://retting.ii.uib.no/USERNAME/inf101.v18.lab2` (*not* the Lab 3 page). Check that your commits appear on the *Commits* sub-page.
+
+* On the overview page, click *(+) Create New... → New merge request*
+
+* Select *USERNAME/inf101.v18.lab2* and *master* as the source branch and *USERNAME/inf101.v18.lab3* and *master* as the target branch, and click *Compare branches and continue*.
+
+* Pick a title for your merge request (or use the default); you can also write a description if you'd like (you should do this in real life, but in this case you're the only one who would read it). Click *Submit merge request*.
+
+* On the next page, you can review the merge request. If everything is OK, there will be a green checkmark, and a *Merge* button. Press it to complete the merge (or explore the interface a bit further, and have a little online discussion with yourself first).
+
+* If everything went well, you are now done with Part I, and can proceed to [Part II – Langton's Ant](LAB-3_II_ANT.md).
+
+* You might also get a merge conflict. This should only happen if you've modified the exercise text, `CellState.java` or something else we didn't expect you to change. If so, you can read the [GitLab documentation on merge requests](https://retting.ii.uib.no/help/user/project/merge_requests/index.md) and [how to resolve conflicts in the GitLab UI](https://retting.ii.uib.no/help/user/project/merge_requests/resolve_conflicts.md). **If you get stuck, ask for help!**
+
+* If everything goes horribly wrong, you can also manually copy your Lab 2 files to Lab 3 (in particular, `MyGrid.java`). 
+
+## Screenshots
+
+### Step 1: Start
+![Screenshot: Starting a new Merge Request](img/1-new-merge-request.png)
+### Step 2: Pick projects and branches
+![Screenshot: Creating the Merge Request](img/2-creating-new-merge-request.png)
+### Step 3: Submit
+![Screenshot: Submitting the Merge Request](img/3-submit-merge-request.png)
+### Step 4: Merge
+![Screenshot: Merging the Merge Request](img/4-merge-merge-request.png)
+### Step 5 (done!)
+![Screenshot: All done](img/5-done.png)
+
+## Part II: Langton's Ant
+
+[Go to Part II](LAB-3_II_ANT.md)