texte encore modifié

texte_explicatif.txt

@@ -40,6 +40,7 @@ git fetch --progress --tags --depth=1 --prune --prune-tags origin
 git reset --hard origin/main 
 git reflog expire --expire=now --all 
 git gc --aggressive --prune=now
+[git clean -qfdx]
 
     git submodule update --init --recursive --force --depth=1 --remote 
 
@@ -66,8 +67,10 @@ git gc --aggressive --prune=now
 
     cette commande supprime les références non reliées et réorganise le dépôt pour l'optimiser. 
     aggressive invoque repack et prend plus de temps. repack défait et refait les packs, qui sont des unités de compression.
+    
+    [git clean -qfdx] si cette commande est absente, les fichiers créés non-committés sont conservés.
 
-Cette combinaison ne permet pas de garder des fichiers ou modifications committé.es, ni de modifications de fichier non-committées. En revanche, elle permet de garder les fichiers créés non-committés.  
+Cette combinaison ne permet de garder aucun changement effectué sur notre dépôt, hormis les créations de fichiers non-committés si git clean est omis. 
 
 # Détails
 Voici un résumé de différentes pistes explorées afin de réduire l'empreinte du dépôt Git. 
@@ -90,22 +93,24 @@ L'usage de la commande git filter-branch est  déconseillé par la documentation
 
 La librairie Java repo-cleaner fonctionne, néanmoins la documentation Git estime que la librairie Python filter-repo est plus rapide et plus sûre. Nous ne souhaitons pas devoir installer Python ou Java donc ne creusons pas plus ces deux possibilités.
 
-Nous souhaitons supprimer tout l'historique sans filtrer, donc la commande git fetch --depth=1 suivie d'un git checkout ou d'un git reset nous convient.
+Nous souhaitons supprimer tout l'historique sans filtrer, donc la commande git fetch --depth=1 suivie d'un git checkout, reset ou merge nous convient.
 
 ## checkout ? merge ? reset  ? 
 Une fois que l'on a fetched les modifications dans notre dossier local remote/, quelle est la meilleure façon de les appliquer à notre index et working directory ? 
+Nous allons comparer 4 possibilités : git merge -X, git merge -s, git reset --hard, git checkout -f -B. Les résultats finaux sont identiques à l'exception de git merge -X.
+ 
+Dans le cas de git merge, on ne souhaite pas résoudre de conflits manuellement. Le remote doit toujours prévaloir sur les différences locales. 
 
-Une première idée est d'utiliser git merge. On ne souhaite pas résoudre de conflits manuellement. Le remote doit toujours prévaloir sur les différences locales. 
-Les commandes git merge -s ours (applique la stratégie ours) et git merge -X theirs (applique la stratégie ort avec l'option theirs) sont intéressantes.
 ### git merge -X theirs
 Cette commande applique une stratégie ort qui en cas de conflit, donne la prévalence à theirs. 
-Néanmoins, puisque l'on travaille en --depth=1, les deux branches n'ont pas d'ancêtre commun, et on doit d'ailleurs fournir l'option --allow-unrelated-histories. L'absence d'ancêtre commun empêche Git de reconnaître les similitudes à l'intérieur d'un même fichier. N'importe quelle modification d'un fichier tracé sur ours, même sur une nouvelle ligne, causera ainsi un conflit et sera écrasée. Cette commande permet tout de même de sauvegarder les fichiers nouvellement créés sur ours, qu'ils soient committés ou non. 
-Elle peut donc se montrer intéressante dans notre cas.
-Un gros inconvénient de cette commande est en cas de délétion d'un fichier sur theirs : il ne sera pas supprimé sur ours.
+Néanmoins, puisque l'on travaille en --depth=1, les deux branches n'ont pas d'ancêtre commun, et on doit d'ailleurs fournir l'option --allow-unrelated-histories. L'absence d'ancêtre commun empêche Git de reconnaître les similitudes à l'intérieur d'un même fichier. N'importe quelle modification d'un fichier tracé sur ours, même sur une nouvelle ligne, causera ainsi un conflit et sera écrasée. Cette commande permet tout de même de sauvegarder les fichiers nouvellement créés et committés sur ours.
+Les fichiers non-committés nouvellement créés sont conservés à moins que git clean soit run.
+Avantage : fichier commités créés sur ours conservés
+Inconvénient : en cas de délétion d'un fichier sur theirs qui existait déjà sur ours : il ne sera pas supprimé sur ours.
 
 ### git merge -s ours
-git merge -s ours va ignorer tous les changements et créations de fichiers committés sur theirs. Elle va également ignorer les modifications non committées. En revanche, les créations de fichier non-committées sont conservées. C'est le même résultat qu'avec la commande git reset --hard. 
-C'est une option intéressante dans notre cas, car on pourrait vouloir sauvegarder uniquement des fichiers de compilation non committés. 
+[attention les notions de theirs et ours sont inversées ici car git merge -s theirs n'existe pas]
+Cette commande applique une stratégie ours qui donne la prévalence à ours, qu'il y ait conflit ou pas. Elle va ignorer tous les changements et créations de fichiers committés sur theirs. Elle va également ignorer les modifications non committées. Les créations de fichier non-committées sont conservées à moins que git clean soit run. C'est le même résultat qu'avec la commande git reset --hard. 
 Comme l'option git merge -s theirs n'existe pas, on doit faire une petite manipulation :
 #on veut merge origin/main sur main, en donnant la prévalence à origin/main
 #création d'une nouvelle branche temporaire temp que l'on check out, sourcée sur origin/main
@@ -118,16 +123,21 @@ git checkout main
 git merge --allow-unrelated-histories temp
 #suppression de temp
 git branch -D temp
+Avantage : 
+Inconvénient : création d'une branche temporaire.
 
 ### git checkout –force -B main origin/main
 
-Cette commande est équivalente à git merge -s ours décrite ci-dessus. Elle évite la petite manipulation de branche temporaire. En revanche, on finit en detached HEAD state, ce qui n'est pas un problème dans notre cas puisque l'on ne souhaite pas push de modification depuis notre dépôt.
+Cette commande est équivalente à git merge -s ours et à git reset --hard, à la différence près que l'on finit en detached HEAD state, ce qui n'est pas un problème dans notre cas puisque l'on ne souhaite pas push de modification depuis notre dépôt.
+Avantage : 
+Inconvénient : detached HEAD state.
 
 ### git reset --hard
-git reset --hard va ignorer tous les changements et créations de fichiers committés sur theirs. Elle va également ignorer les modifications non committées. En revanche, les créations de fichier non-committées sont conservées. C'est le même résultat qu'avec la commande git merge -s ours, mais en une ligne.
-C'est une option intéressante dans notre cas, car on pourrait vouloir sauvegarder uniquement des fichiers de compilation non committés. 
+git reset --hard est équivalente à git merge -s ours et git checkout --force -B.
+Avantage : 
+Inconvénient :
 
-Les tests nous montrent que les options les plus économes en mémoire sont git merge -s ours et git --reset hard, qui font la même chose. Néanmoins git reset --hard tient en une ligne et n'implique pas la création d'une branche temporaire, c'est donc celle que nous retenons.
+Les tests nous montrent que les options les plus économes en mémoire sont git checkout -force -B, git merge -s ours, git --reset hard, qui font la même chose. Néanmoins git reset --hard n'implique pas la création d'une branche temporaire et ne finit pas en detached HEAD state, c'est donc celle que nous retenons.
 
 ### Gestion des submodules
 Les submodules sont clonés au début via les options de git clone --recurse-submodules --remote-submodules.