computer lab alpha

MOSIG_AdvancedBasic2h/git-model-computer-lab.tex

@@ -283,126 +283,129 @@ Check that HEAD points on the right commit of the \texttt{master} branch.
 
 And now merge the \texttt{develop} branch in master.
 \begin{minted}{console}
-git merge develop
+$ git merge develop
 \end{minted}
 
 Check that the commit has two parents and the all the three trees
 point to the same file.
 
-\section{Git perd la tête~?}
+\section{Headless Git}
 
-Dans cette section, nous allons comprendre comment un dépôt peut se
-retrouver dans une situation de «~tête détachée~» et pourquoi il
-convient de prendre ses précautions dans ce cas-là.
+This section discuss about ``detached head'': why do you pass in this
+state, and what to do to avoid trouble.
 
-\subsection{Reprendre le travail depuis un commit antérieur}
+\subsection{Get the work directory state of a previous commit}
+\label{sec:headless}
 
-Récupérez l'identifiant du commit correspondant à la branche
-\texttt{develop}. On peut par exemple utiliser~:
+Get the SHA-1 value of the last commit of \texttt{develop} using the
+following command:
 \begin{minted}{console}
-git show develop
+$ git show develop
 \end{minted}
 
-Notez l'identifiant du commit, et récupérez (\texttt{checkout}) les
-données de ce commit~:
+Get the working directory related to this commit (\texttt{checkout})~:
 \begin{minted}{console}
-git checkout <numéro-du-commit>
+$ git checkout <SHA-1 commit>
 \end{minted}
 
-Normalement, Git doit vous avertir que vous passez en état «~tête
-détachée~», mais c'est simplement un avertissement.
+Git should warn you about a ``detached head'' state.
 
-Créez un nouveau fichier et faites un commit~:
+Create a new file and register it with a new commit:
 \begin{minted}{console}
-mon_editeur_prefere fichier3.txt # inserer quelques lignes
-git add fichier3.txt
-git commit -m "message détaché 1"
+$ emacs file3.txt # insert few lines
+$ git add file3.txt
+$ git commit -m "detached head message 1"
 \end{minted}
 
-Vérifiez que votre commit est bien dans le journal des révisions~:
+Check that the commit is fully known by Git:
 \begin{minted}{console}
-git log --graph --oneline
+$ git log --graph --oneline
 \end{minted}
 
-Notez mentalement le numéro de commit. Revenez à la branche master et
-regardez le journal des révisions~:
+Note well this commit number and then move to the \texttt{master}
+branch:
 \begin{minted}{console}
-git checkout master
-git log --graph --oneline
+$ git checkout master
+$ git log --graph --oneline
 \end{minted}
 
-Mais où est donc passé le commit dans lequel vous aviez ajouté le
-fichier \texttt{fichier3.txt}~? Il n'est référencé par aucune branche,
-donc inaccessible, sauf si l'on connaît précisément son identifiant
-(ou alors si l'on fait une recherche exhaustive dans les fichiers du
-dépôt).
+But now, where is the commit with \texttt{file3.txt}? No branch
+references it. Unless you remember the SHA-1, you may have to dig into
+the logs:
+\begin{itemize}
+\item look into HEAD history (\texttt{logs/refs/HEAD}) for the title
+  of the commit
+\item if you know some ``exclusive'' content of the commit, look into
+  the whole set of file content by using the full list of revision and
+  \mintinline{console}{git-grep}:
+\begin{minted}{console}
+$ git rev-list --all | xargs git grep <PATTERN>
+\end{minted}
+\item do a full search in the blob list, excluding, first, those
+  already in some branches.
+\end{itemize}
 
-Dans un dépôt Git, les seuls fichiers visibles facilement sont les
-fichiers qui sont des ancêtres d'un point d'entrée de l'arbre des
-révisions, ces points d'entrée étant~:
+In a Git repository, the only easily visible files are in the ancestor
+commits of a entry point:
 \begin{itemize}
-\item des branches~;
-\item des tags~;
-\item le pointeur \texttt{HEAD} (la tête).
+\item branches;
+\item tags;
+\item \texttt{HEAD}.
 \end{itemize}
 
-Nous allons rendre notre commit visible en la fusionnant dans
-la branche \texttt{develop}~:
+Hopefully, you remember fully the SHA-1 and thus it is much easier to
+manage. Two non-exclusive example methods follows.
+
+First, merge the commit in the \texttt{develop} branch:
 \begin{minted}{console}
-git checkout develop
-git merge <numéro-du-commit> # le numéro est celui du commit
-                             # dans lequel on a créé fichier3.txt
+$ git checkout develop
+$ git merge <commit SHA-1> # commit with file3.txt
 \end{minted}
 
-Une autre solution possible était de créer une nouvelle branche
-directement à partir de ce numéro de commit, avec%
-\mintinline{bash}{git branch <nouvelle-branche> <numéro-du-commit>}.
+Second, create a new branch with the commit number.
+\mintinline{console}{$ git branch <BRANCH NAME> <commit SHA-1>}.
 
-\subsection{Reprendre le travail depuis une branche antérieure}
+\subsection{Working with another branch}
 
-Revenez sur la branche master~:
+Come back to the \texttt{master}:
 \begin{minted}{console}
-git checkout master
+$ git checkout master
 \end{minted}
 
-Nous allons maintenant effectuer les mêmes opérations mais en
-repartant de la branche \texttt{develop}, et non de son commit
-associé.
+Redo the same manipulation as in subsection \ref{sec:headless}, but
+using the branch name \texttt{develop} instead of the commit number of
+the branch.
 
 \begin{minted}{console}
-git checkout develop
-mon_editeur_prefere fichier3.txt # inserer quelques lignes
-git add fichier3.txt
-git commit -m "message dev2"
-git checkout master
+$ git checkout develop
+$ emacs file3.txt # insert few lines
+$ git add file3.txt
+$ git commit -m "message dev2"
+$ git checkout master
 \end{minted}
 
-Revenez sur la branche \texttt{develop} et vérifiez que rien n'est
-perdu~:
+Comme back to \texttt{develop} and check that the commit is there:
 \begin{minted}{console}
 git checkout develop
 git log --graph --oneline
 \end{minted}
 
-C'est normal. Lorsque l'on travaille à partir d'une branche, le
-pointeur de la branche avance avec la tête. Lorsque l'on change de
-branche, nos commits ne sont pas perdus.
+The pointer of the branch follows HEAD and advances with it. It is
+much easier to change HEAD for another branch without loosing any
+commit.
+
+\subsection{And with the tags?}
 
-\subsection{Et les tags, dans tout ça~?}
+If you come back to the tag \texttt{v0.1} from section~\ref{sec:tags},
+are you in a detached head state, or not ? Why ?
 
-Revenez au tag \texttt{v0.1} créé dans la section~\ref{sec:tags}. À
-votre avis, êtes-vous en situation de tête détachée (comme si vous
-aviez récupéré un numéro de commit), ou pas~? Pourquoi~?
+Try and check !
 
-\section{Pour conclure\dots{}}
+\section{Conclusion\dots{}}
 
-À l'issue de ce TP, vous devriez avoir une compréhension détaillée des
-structures de données sous-jacentes au stockage de l'historique d'un
-dépôt. C'est un graphe orienté, avec un certain nombre de points
-d'entrées.  La plupart des commandes de Git servent soit à créer de
-nouveaux nœuds dans le graphe, soit à créer de nouveaux points
-d'entrée, soit à naviguer. Si vous avez compris cela, vous avez tout
-compris.
+Git data storage is addressable by content. The link between files are
+a direct acyclic graph, with several source (entry points). Most Git
+commands create new nodes, new sources or navigate in the graphe.
 
 \end{document}