diff --git a/handson.tex b/handson.tex
index 1a46e2d30e6368d3d35989e5a4d0639b143150bb..270ea8f0affc562200d2bb2bc4e0c8f5e87d3d46 100644
--- a/handson.tex
+++ b/handson.tex
@@ -102,6 +102,66 @@ To ssh://git@gitlab.control.lth.se:/frt090-2014/playground.git
 \section{Handling Conflicts}
 
 If the previous push command went as shown, you happened to be the
-first in tyhe group to perform a push.
-
+first in the group to perform a push. Instead you might see something similar to
+\begin{lstlisting}
+andersn@fiol:../andersn/work/playground\$ git push
+To git@gitlab.control.lth.se:frt090-2014/playground.git
+ ! [rejected]        master -> master (fetch first)
+error: failed to push some refs to 'git@gitlab.control.lth.se:frt090-2014/playground.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.
+\end{lstlisting}
+I basically says that someone else performed a succesful \emph{push}
+to the repository server sometime between your latest succesful
+\emph{pull} operation and the failed \emph{push}. The message also
+tells you what to do to solve the problem, perform a \emph{git pull}
+and see what happens.
+\begin{lstlisting}
+andersn@fiol:../andersn/work/playground\$ git pull
+remote: Counting objects: 5, done.
+remote: Compressing objects: 100\% (2/2), done.
+remote: Total 3 (delta 1), reused 0 (delta 0)
+Unpacking objects: 100\% (3/3), done.
+From gitlab.control.lth.se:frt090-2014/playground
+   eb02c3c..0bf182c  master     -> origin/master
+Auto-merging Readme
+CONFLICT (content): Merge conflict in Readme
+Automatic merge failed; fix conflicts and then commit the result.
+\end{lstlisting}
+If git manages to merge the changes you will just get a message saying
+all went well. If the different versions can not be automatically
+merged together you will be notified about the conflict instead, as
+shown above.  To resolve the conflict you have to open the file(s)
+where there is a conflict and decide yourself which version should be
+used. In this example the \emph{Readme} file now looks like this.
+\begin{verbatim}
+A phony repo used for tutorial purposes.
+<<<<<<< HEAD
+A second line.
+=======
+Another second line change.
+>>>>>>> 0bf182c3ae6abc94a75c0c4e27df85f6cf7d82e4
+\end{verbatim}
+Here we see the two versions of the second line within conflict
+markers. Edit the file as you wish, then save, commit, and try to push
+again.
+
+\section{Continue}
+\label{sec:cont}
+
+Keep on playing with the playground repository to get familiarized with git. 
+\begin{itemize}
+\item Add new files to the repository.
+\item Try some other git commands; \emph{diff}, \emph{log}, \emph{blame}
+\item Try to add and/or modify a \emph{.gitignore} file. It is very
+  useful for hiding away certain file names (or patterns) that you do
+  not want to have within version control. For example .class files if
+  you program in Java, or .o files from C/C++.
+\item Point a web browser to \texttt{http://gitlab.control.lth.se},
+  find the playground project and play around with the functionality
+  in gitlab.
+\end{itemize}
 \end{document}
\ No newline at end of file