Différences

Ci-dessous, les différences entre deux révisions de la page.

--- prog:git [2025/10/20 15:34] – [Génération de la clé] : utilisation de sign only root
+++ prog:git [2025/11/24 11:32] (Version actuelle) – Ajout de "Retravailler l'historique" root
@@ Ligne 1: / Ligne 1: @@
+=====Téléchargement=====
+====Windows====
+[[https://gitforwindows.org|Site Web]], {{ :prog:git:git-2.21.0-64-bit.exe |Archive git gui 64 bit 2.21.0 (26/02/2019)}}
+[[http://matthew-brett.github.io/pydagogue/git_gui_windows.html|Getting started with git gui on Windows]] {{ :prog:git:getting_started_with_git_gui_on_windows_pydagogue_0.2_documentation_2019-10-22_13_33_19_.html |Archive le 22/10/2019}}
 =====Dépôts=====
-====Cloner et configurer d'un dépôt====
-<code bash>
+====Configurer====
-git clone https://github.com/bansan85/2lgc.git
-</code>
+===Options globales===
-Mais surtout, ne pas oublier (l'option ''--global'' configure tous les dépôts et pas uniquement le dépôt courant) :
+Ne pas oublier (l'option ''%%--%%global'' configure tous les dépôts et pas uniquement le dépôt courant) :
 <code bash>
@@ Ligne 56: / Ligne 63: @@
 [[https://stackoverflow.com/questions/59061816/git-forces-refresh-index-after-switching-between-windows-and-linux|git forces refresh index after switching between Windows and Linux]] {{ :prog:git:git_forces_refresh_index_after_switching_between_windows_and_linux_-_stack_overflow_05_01_2023_11_14_41_.html |Archive du 27/11/2019 le 05/01/2023}}
-===Ne pas télécharger l'historique===
-Pratique pour ne faire que de la compilation et alléger le téléchargement.
-Ajouter ''%%--%%depth 1'' après ''git clone''.
-===Télécharger uniquement une seule branche===
+=====Clés publiques / privées=====
-  git clone --single-branch --branch llvmorg-8.0.0 https://github.com/llvm/llvm-project.git
-====Un dépôt global ou un dépôt par projet / dépendance====
+Pour signer les commits, il faut commencer par avoir la clé publique et privée.
-C'est l'éternel débat. Est-il mieux d'avoir un projet par dépendance internes ou un unique projet global.
-Ici, je suppose qu'il y a une équipe d'une trentaine de personnes qui travaille sur le même projet.
+====Génération de la clé====
-De par mon expérience, je conseille un projet par librairie / exécutable générée mais chaque choix a ses avantages / inconvénients.
+<code bash>
+gpg --full-generate-key
+</code>
-^Problématique               ^ Un projet par dépendance         ^^ Un projet unique ^^
+Choisir une clé ''RSA (sign only)'' de la taille maximale (4096). ''RSA'' signe plus rapidement que ''DSA'' (qui vérifie plus rapidement). Dans mon cas, ce qui m'intéresse, c'est que les commits soient signés rapidement sur ma machine.
-^ :::                        ^ X                 ^    V            ^ Y     ^ V       ^
-| Nombres de dépôts git      | {{ :img:cc0:dislike-157252.svg?20 |}} | Nombreux dépôts git.  | {{ :img:cc0:hand-157251.svg?20 |}} | Un seul dépôt git. |
-| Gestion des submodules     | {{ :img:cc0:dislike-157252.svg?20 |}} | Nécessite un super projet uniquement pour gérer la version des submodules. | {{ :img:cc0:hand-157251.svg?20 |}} | Pas de super projet. |
-| :::                        | {{ :img:cc0:hand-157251.svg?20 |}} | Chaque super projet peut avoir une version différente des submodules en cas de modification d'API. | {{ :img:cc0:dislike-157252.svg?20 |}} | Un changement d'API nécessite une modification de tous les autres composants dépendants. |
-| :::                        | {{ :img:cc0:dislike-157252.svg?20 |}} | Hétérogénéité des versions des submodules (dette technique). | {{ :img:cc0:hand-157251.svg?20 |}} | Les submodules sont toujours à jour. |
-| Travail en groupe          | {{ :img:cc0:dislike-157252.svg?20 |}} | ''git submodule foreach git fetch'' est nécessaire pour savoir si des sous-modules ont évolués | {{ :img:cc0:hand-157251.svg?20 |}} | Les submodules sont toujours à jour. |
-| :::                        | {{ :img:cc0:hand-157251.svg?20 |}} {{ :img:cc0:dislike-157252.svg?20 |}} | Il y a moins de risque de conflit lors du commit des dépendances mais toujours autant dans le super projet. Mais dans le super projet, le fetch + checkout remet à jour les dépots et pas besoin de merge / rebase.  | {{ :img:cc0:dislike-157252.svg?20 |}} | Fetch / merge / rebase souvent nécessaire lors des commits |
-| :::                        | {{ :img:cc0:dislike-157252.svg?20 |}} | Pour appliquer une modification, il faut faire un commit dans la dépendance et un second dans le super projet | {{ :img:cc0:hand-157251.svg?20 |}} | Un seul commit est nécessaire. |
-Conclusion : si l'équipe n'est pas trop grande, je conseillerais un seul super projet. Si l'équipe est très grande avec plusieurs très gros projet (ayant des dépendances en commun) et de nombreux commits (ce qui nécessiterait un rebase à chaque fois), il est nécessaire de multiplier les dépôts. Dans ce dernier cas, il sera nécessaire de commencer par stabiliser l'interface de chaque composant pour ne pas être obligé de passer son temps à suivre les mises à jour des submodules ou encore pouvoir mettre à jour facilement un vieux projet auparavant abandonné.
+====Afficher la clé publique et privée====
-====Changer l'adresse d'un dépôt====
-Pour connaître l'adresse actuelle :
 <code bash>
-git remote -v
+gpg --list-secret-keys --keyid-format LONG
 </code>
-Pour la modifier :
+Avec ''YYYYYYYYY'' l'id de la ligne ''sec rsa4096/YYYYYYYYY''
+Pour exporter la clé publique :
 <code bash>
-git remote set-url origin https://github.com/USERNAME/OTHERREPOSITORY.git
+gpg --armor --export YYYYYYYYY
 </code>
-[[https://help.github.com/articles/changing-a-remote-s-url/|Changing a remote's URL - User Documentation]] {{ :prog:git:changing_a_remote_s_url_-_github_help_2019-10-22_13_30_20_.html |Archive le 22/10/2019}}
+Pour exporter la clé privée :
-====Déplacer un dossier vers au nouveau dépôt====
+<code bash>
-<WRAP center round important 60%>
+gpg --export-secret-keys YYYYYYYYY > file.key
-Il faut créer un double du clone du dépôt car c'est le dossier du dépôt en cours qui va être converti vers un nouveau dépôt.
+</code>
-</WRAP>
-[[https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/|Splitting a subfolder out into a new repository]] {{ :prog:git:splitting_a_subfolder_out_into_a_new_repository_-_github_help_2019-10-22_13_30_27_.html |Archive le 22/10/2019}}
+====Configurer git====
-====Fusionner deux dépôts en un seul====
+Pour importer une clé privée :
-Depuis le projet A :
+<code bash>
+gpg --import file.key
+</code>
+Si on souhaite ajouter la signature des commits pour tous les projets.
 <code bash>
-git remote add -f Bproject path/to/B
+git config --global user.signingkey YYYYYYYYY
-git merge -s ours --no-commit --allow-unrelated-histories Bproject/master
+git config --global commit.gpgsign true
-rm -Rf path/to/B
-git read-tree --prefix=path/to/B -u Bproject/master
-git commit -m "Merge B project as our subdirectory"
 </code>
-Supprimer le submodule des fichiers ''.gitmodules'', ''.git/config'' et supprimer le dossier ''.git/modules/path/to/B''
+====Mettre à jour la clé====
+Il faut connaître le numéro de la clé.
 <code bash>
-git add .gitmodules
+gpg --list-keys --keyid-format=long
-git commit -m "Remove submodule B project"
 </code>
-[[https://stackoverflow.com/questions/23327701/git-merge-submodule-into-parent-tree-cleanly-and-preserving-commit-history|Git merge submodule into parent tree cleanly and preserving commit history]] {{ :prog:git:git_merge_submodule_into_parent_tree_cleanly_and_preserving_commit_history_-_stack_overflow_22_09_2023_12_24_09_.html |Archive du 27/04/2014 le 22/09/2023}}
+Le numéro de la clé est celui du pub après l'algorithme (''NUMERONUMERONUEM'' ci-dessous).
-Ou
+<code>
+pub   rsa4096/NUMERONUMERONUEM 2020-08-09 [SC] [expires: 2022-08-11]
+      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+uid                 [ unknown] USERNAME <mail@example.com>
+sub   rsa4096/XXXXXXXXXXXXXXXX 2020-08-09 [E] [expires: 2022-08-11]   </code>
+====Date d'expiration====
+Pour mettre à jour la date d'expiration, il faut faire :
 <code bash>
-cd main
+gpg --edit-key KEY_ID
-# Cette commande doit impérativement être lancée depuis la racine du dépôt git et pas à l'emplacement du futur nouveau dossier.
+list
-git fetch ../other master:tmp
+key 0
-git checkout tmp
+expire
-git filter-branch --index-filter \
+key 1
-    'git ls-files -s | sed "s-\t\"*-&sub/-" |
+expire
-        GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
+save
-            git update-index --index-info &&
-     mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"'
-git rebase master
-git checkout master
-git merge tmp
-git branch -d tmp
-git update-ref -d refs/original/refs/heads/tmp
 </code>
-[[https://blog.rom1v.com/2017/07/fusionner-deux-depots-git/|Fusionner deux dépôts git]] {{ :prog:git:fusionner_deux_depots_git_rom1v_blog_2019-10-22_13_30_34_.html |Archive du 12/07/2017 le 22/10/2019}}
+Ne pas choisir une date d'expiration supérieure à 1 an. C'est la limite de sécurité généralement considérée comme sûr.
+Pour la mettre à jour sur GitHub, il faut supprimer la clé publique précédente avant de la rajouter. Sinon GitHub détecte que la clé publique a déjà été importée mais il ne détecte pas le changement de date.
+[[https://makandracards.com/makandra-orga/13644-what-to-do-when-your-gpg-pgp-key-expires|What to do when your GPG/PGP key expires]] {{ :prog:git:what_to_do_when_your_gpg_pgp_key_expires_-_makandra_orga_2021-08-11_20_28_16_.html |Archive du 2013 le 11/08/2021}}
+====Cloner====
+<code bash>
+git clone https://github.com/bansan85/2lgc.git
+</code>
+  * Ne pas télécharger l'historique
+Pratique pour ne faire que de la compilation et alléger le téléchargement.
+Ajouter ''%%--%%depth 1'' après ''git clone''.
+  * Télécharger uniquement une seule branche
+  git clone --single-branch --branch llvmorg-8.0.0 https://github.com/llvm/llvm-project.git
-====Dupliquer un dépôt====
+====Dupliquer un dépôt contenant du lfs====
 Il faut commencer par le cloner si ce n'est pas déjà fait.
@@ Ligne 163: / Ligne 180: @@
 [[https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository|Duplicating a repository]] {{ :prog:git:duplicating_a_repository_-_github_docs_12_09_2022_12_48_10_.html |Archive du 25/02/2022 le 12/09/2022}}
+=====Submodules=====
+====Supprimer un submodule====
+<code bash>
+git submodule deinit <path_to_submodule>
+git rm <path_to_submodule>
+git commit -m "Removed submodule"
+rm -rf .git/modules/<path_to_submodule>
+</code>
+[[https://gist.github.com/myusuf3/7f645819ded92bda6677#gistcomment-2650640|How effectively delete a git submodule?]] {{ :prog:git:how_effectively_delete_a_git_submodule._github_2019-10-22_13_32_38_.html |Archive du 18/07/2018 le 22/10/2019}}
+====Changer l'url/remote d'un submodule====
+<code bash>
+git submodule set-url -- <local_path> <new_url>
+</code>
 =====Branches=====
 ====Mettre à jour une branche qui s'est éloignée du maître====
 [[https://stackoverflow.com/questions/3876977/update-git-branches-from-master|Update Git branches from master]] {{ :prog:git:git_branch_-_update_git_branches_from_master_-_stack_overflow_2019-10-22_13_30_54_.html |Archive du 06/10/2010 le 22/10/2019}}
@@ Ligne 222: / Ligne 260: @@
 Il est interdit d'utiliser ''%%--%%force''. Cela peut effacer le travail des autres car ''%%--%%force-with-lease'' va vérifier que la branche locale est synchro avec la branche distance. Si on ne vérifie pas la branche distance (avec ''%%--%%force''), on peut effacer le travail des autres.
+====Se resynchroniser après qu'un projet ait accepté la pull request====
+Ou le syndrome github du ''This branch is X commits behind''. Depuis le dépôt cloné :
+<code bash>
+git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
+git fetch upstream
+git checkout master
+git merge upstream/master
+</code>
+[[https://help.github.com/articles/configuring-a-remote-for-a-fork/|Configuring a remote for a fork - User Documentation]] {{ :prog:git:configuring_a_remote_for_a_fork_-_github_help_2019-10-22_13_31_02_.html |Archive le 22/10/2019}}
+[[https://help.github.com/articles/syncing-a-fork/|Syncing a fork - User Documentation]] {{ :prog:git:syncing_a_fork_-_github_help_2019-10-22_13_31_08_.html |Archive le 22/10/2019}}
 =====Commit=====
 ====Tags====
 Suppression d'un tag déjà push
 <code bash>
@@ Ligne 237: / Ligne 290: @@
 ====Annulation d'une modification non encore "commitée"====
 <code bash>
 git checkout -- <fichier>
@@ Ligne 242: / Ligne 296: @@
 ====Afficher les différences====
 Avant ''git add''
 <code bash>
@@ Ligne 255: / Ligne 310: @@
 ====Trouver le commit à l'origine d'un bug====
 <code bash>
 git bisect start
@@ Ligne 283: / Ligne 339: @@
 Il est théoriquement inutile de supprimer le dossier de compilation et de repartir à chaque fois à 0. Mais, parfois, le système de compilation (autotools) se trompe dans les dépendances et ne recompile pas tout ce qui devrait l'être. Cela crée des bugs à l'exécution qui n'en sont pas forcément.
-====Se resynchroniser après qu'un projet ait accepté la pull request====
+====Importer un commit depuis un autre dépôt====
-Ou le syndrome github du ''This branch is X commits behind''. Depuis le dépôt cloné :
-<code bash>
-git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
-git fetch upstream
-git checkout master
-git merge upstream/master
-</code>
-[[https://help.github.com/articles/configuring-a-remote-for-a-fork/|Configuring a remote for a fork - User Documentation]] {{ :prog:git:configuring_a_remote_for_a_fork_-_github_help_2019-10-22_13_31_02_.html |Archive le 22/10/2019}}
-[[https://help.github.com/articles/syncing-a-fork/|Syncing a fork - User Documentation]] {{ :prog:git:syncing_a_fork_-_github_help_2019-10-22_13_31_08_.html |Archive le 22/10/2019}}
-====Changer le message de tous les commit automatiquement====
-  git filter-branch -f --msg-filter 'sed "s/^git-svn-id.*$//"' -- --all
-Cela enlève toutes les lignes commençant par ''git-svn-id'' pour tous les commits ''%%-- --all%%''.
-====Importer un commit depuis un autre dépôt====
 Il faut ajouter le nouveau dépôt, faire un fetch puis utiliser la commande ''cherry-pick''.
@@ Ligne 317: / Ligne 358: @@
 git cherry-pick -Xrename-threshold=5% -x SHA
 </code>
 ====Importer seulement un fichier d'un commit====
 <code bash>
 git show SHA -- file1.txt file2.txt | git apply -
@@ Ligne 341: / Ligne 384: @@
 Mais attention, en cas de signature avec une clé GPG, la date du commit sera toujours l'actuelle.
-=====Subtree=====
-Les subtree utilisent les ''remote'' plutôt que les ''submodules''.
-====Ajout d'un subtree====
+====Signer tous les commits existants====
-<code bash>
-git remote add -f name url_repository
-git subtree add --prefix folder url_repository branch
-</code>
-avec :
-  * ''folder'' : le dossier qui contiendra le ''subtree'',
-  * ''url_repository'' : l'url de dépôt git du ''subtree'',
-  * ''branch'' : la branch (master par exemple).
-Dans le cas d'une architecture ''subtree'', l'historique des ''subtree'' est ajouté au super projet. Si ce n'est pas souhaité, il faut ajouter ''%%--squash%%''
+Cela réécrit tout l'arbre git.
-''git subtree add'' ne fonctionne que sur un dépôt ayant déjà au moins un commit.
+  git filter-branch -f --commit-filter 'git commit-tree -S "$@"' HEAD
+  git push -f
-====pusher un subtree====
+[[https://stackoverflow.com/questions/13043357/git-sign-off-previous-commits|Git sign off previous commits?]] {{ :prog:git:git_sign_off_previous_commits_-_stack_overflow_2019-10-22_13_32_56_.html |Archive du 24/10/2012 le 22/10/2019}}
-Faire un commit de façon traditionnelle.
-La technique consiste à ''pusher'' sur les dépôts distants puis à synchroniser le dépôt principal.
+====Avoir tous les enfants d'un commit====
-  git subtree push --prefix=folder remote_name branch
+<code bash>
+find_descendants() {
+    local sha=$1
+    line=$(git rev-list --all --children | grep ^$sha)
-Mais en faisant simplement çà, on se retrouve avec des commits différents entre le dépot principal et le dépot ''subtree''. Il faut donc les synchroniser à nouveau :
+    if [[ $line == *" "* ]]; then
+        children=$(echo $line | cut -d' ' -f2-)
+        for child in $children; do
+            echo $child
+            find_descendants $child
+        done
+    fi
+}
-====Récupérer les modifications d'une branche====
+find_descendants $1
+</code>
-  git subtree pull --prefix=folder remote_name branch
+=====État du dépôt=====
-Et c'est très moche dans l'historique de git :
+====Si des fichiers ont été modifiés====
-{{:prog:git:git_historique_subtree.png|Historique git avec subtree et plusieurs branches}}
+<code bash>
+if [[ ! -z "$(git status --porcelain --ignore-submodules)" ]]
+then
+  echo "Some files has been modified."
+  exit 1
+fi;
+</code>
-En plus, dans le ''pull'', on ne peut pas faire un commit pour deux branches distinctes.
+Pour utiliser ''%%git diff-index --name-only HEAD --%%'', il est nécessaire d'appeler ''%%git update-index --refresh%%''. [[https://stackoverflow.com/questions/34807971/why-does-git-diff-index-head-result-change-for-touched-files-after-git-diff-or-g|Why does git diff-index HEAD result change for touched files after git diff or git status?]] {{ :prog:git:why_does_git_diff-index_head_result_change_for_touched_files_after_git_diff_or_git_status_-_stack_overflow_1_19_2024_4_04_53_pm_.html |Archive du 15/01/2016 le 19/01/2024}}
-Je ne comprends pas pourquoi les ''subtree'' sont considérés par certains comme mieux que les submodules.
+====Si des fichiers non ignorés ont été ajoutés====
-[[https://delicious-insights.com/fr/articles/git-subtrees/|Comprendre et maîtriser les subtrees Git]] {{ :prog:git:comprendre_et_maitriser_les_subtrees_git_delicious_insights_2019-10-07_23_58_57_.html |Archive du 30/01/2015 le 07/10/2019}}
+<code bash>
+if [ -n "$(git ls-files --others --exclude-standard)" ]
+</code>
-[[https://gauthier.frama.io/post/git-subtree/|Git subtree: une alternative à Git submodule]] {{ :prog:git:git_subtree_une_alternative_a_git_submodule_le_blog_de_gauthier_2019-10-07_00_00_35_.html |Archive du 15/05/2019 le 08/10/2019}}
+=====Maintenance=====
-[[https://tsh.io/blog/git-subtree-or-how-i-stopped-worrying-and-learned-to-love-external-dependencies/|Git subtree or how I stopped worrying and learned to love external dependencies]] {{ :prog:git:how_i_learned_to_love_external_dependencies_tsh.io_2019-11-21_10_43_04_.html |Archive du 27/11/2018 le 21/11/2019}}
+====Changer l'adresse d'un dépôt====
-=====Historique=====
+Pour connaître l'adresse actuelle :
-====Chercher dans le code sur l'ensemble des commits====
-  git grep <regexp> $(git rev-list --all)
-Attention, cela cherche dans tous les fichiers, pas uniquement dans les modifications du commit.
-====Chercher dans le code uniquement les modifications====
-  git log -S"a chercher"
-====Trouver le commit qui supprime un fichier====
-Il n'y a pas moyen. Mais on peut retrouver tous les commits modifiant un fichier précis.
-  git log --full-history -- your_file
-Le dernier sera celui l'ayant supprimé.
-====Chercher une modification également dans les sous-modules====
-  git submodule foreach git log -S"Pattern"
-====Annuler temporairement des modifications====
-Les modifications sont stockés sous forme d'une liste FILO.
-  * Stocke les modifications dans une zone ''nom_memoire''.
 <code bash>
-git stash push -m nom_memoire fichiers
+git remote -v
 </code>
-  * Restaure les modifications
+Pour la modifier :
 <code bash>
-git stash apply
+git remote set-url origin https://github.com/USERNAME/OTHERREPOSITORY.git
-# Il est possible d'appliquer les modifications sans enlever la dernière zone mémoire.
-git stash drop
-# Ou il est possible de tout faire en même temps.
-git stash pop
 </code>
-====Ignorer certains commits avec blame====
+[[https://help.github.com/articles/changing-a-remote-s-url/|Changing a remote's URL - User Documentation]] {{ :prog:git:changing_a_remote_s_url_-_github_help_2019-10-22_13_30_20_.html |Archive le 22/10/2019}}
-Inscrire les numéros de commit (un par ligne) dans un fichier ''.git-blame-ignore-revs''.
-====Modifier une liste de commits====
+====Déplacer un dossier vers au nouveau dépôt====
-Applique ''clang-format'' pour tous les fichiers ''.cpp'' ayant changés.
+<WRAP center round important 60%>
+Il faut créer un double du clone du dépôt car c'est le dossier du dépôt en cours qui va être converti vers un nouveau dépôt.
+</WRAP>
-<code bash>
+[[https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/|Splitting a subfolder out into a new repository]] {{ :prog:git:splitting_a_subfolder_out_into_a_new_repository_-_github_help_2019-10-22_13_30_27_.html |Archive le 22/10/2019}}
-git filter-branch --tree-filter 'git-clang-format $(\
-  git diff-index --diff-filter=AM --name-only $GIT_COMMIT |\
-    grep .cpp)' -- <SHA1>..HEAD
-</code>
-[[https://stackoverflow.com/questions/43974371/run-git-clang-format-on-series-of-git-commits|Run git-clang-format on series of git commits]] {{ :prog:git:formatting_-_run_git-clang-format_on_series_of_git_commits_-_stack_overflow_27_03_2023_10_03_57_.html |Archive du 15/05/2017 le 27/03/2023}}
+====Fusionner deux dépôts en un seul et en conservant l'historique====
-=====État du dépôt=====
+Depuis le projet A :
-====bash====
+<code bash>
+git remote add -f Bproject path/to/B
+git merge -s ours --no-commit --allow-unrelated-histories Bproject/master
+rm -Rf path/to/B
+git read-tree --prefix=path/to/B -u Bproject/master
+git commit -m "Merge B project as our subdirectory"
+</code>
-  * Si des fichiers ont été modifiés
+Supprimer le submodule des fichiers ''.gitmodules'', ''.git/config'' et supprimer le dossier ''.git/modules/path/to/B''
 <code bash>
-if [[ ! -z "$(git status --porcelain)" ]]
+git add .gitmodules
-then
+git commit -m "Remove submodule B project"
-  echo "Some files has been modified."
-  exit 1
-fi;
 </code>
-Pour utiliser ''%%git diff-index --name-only HEAD --%%'', il est nécessaire d'appeler ''%%git update-index --refresh%%''. [[https://stackoverflow.com/questions/34807971/why-does-git-diff-index-head-result-change-for-touched-files-after-git-diff-or-g|Why does git diff-index HEAD result change for touched files after git diff or git status?]] {{ :prog:git:why_does_git_diff-index_head_result_change_for_touched_files_after_git_diff_or_git_status_-_stack_overflow_1_19_2024_4_04_53_pm_.html |Archive du 15/01/2016 le 19/01/2024}}
+[[https://stackoverflow.com/questions/23327701/git-merge-submodule-into-parent-tree-cleanly-and-preserving-commit-history|Git merge submodule into parent tree cleanly and preserving commit history]] {{ :prog:git:git_merge_submodule_into_parent_tree_cleanly_and_preserving_commit_history_-_stack_overflow_22_09_2023_12_24_09_.html |Archive du 27/04/2014 le 22/09/2023}}
-  * Si des fichiers non ignorés ont été ajoutés
+Ou
 <code bash>
-if [ -n "$(git ls-files --others --exclude-standard)" ]
+cd main
+# Cette commande doit impérativement être lancée depuis la racine du dépôt git et pas à l'emplacement du futur nouveau dossier.
+git fetch ../other master:tmp
+git checkout tmp
+git filter-branch --index-filter \
+    'git ls-files -s | sed "s-\t\"*-&sub/-" |
+        GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
+            git update-index --index-info &&
+     mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"'
+git rebase master
+git checkout master
+git merge tmp
+git branch -d tmp
+git update-ref -d refs/original/refs/heads/tmp
 </code>
-=====Maintenance=====
+[[https://blog.rom1v.com/2017/07/fusionner-deux-depots-git/|Fusionner deux dépôts git]] {{ :prog:git:fusionner_deux_depots_git_rom1v_blog_2019-10-22_13_30_34_.html |Archive du 12/07/2017 le 22/10/2019}}
 ====Vérifie l'état d'un dépôt====
@@ Ligne 484: / Ligne 527: @@
 </code>
-====Avoir tous les enfants d'un commit====
+====Suppression des dangling blobs====
-<code bash>
-find_descendants() {
-    local sha=$1
-    line=$(git rev-list --all --children | grep ^$sha)
-    if [[ $line == *" "* ]]; then
-        children=$(echo $line | cut -d' ' -f2-)
-        for child in $children; do
-            echo $child
-            find_descendants $child
-        done
-    fi
-}
-find_descendants $1
-</code>
-====Suppression des dangling blobs====
 Ces commits inachevés sont détectés par la commande
 <code bash>
@@ Ligne 515: / Ligne 541: @@
 ====Ne garder que la dernière version après un git pull====
 <code bash>
 git checkout --orphan master
 git gc --prune=all
 </code>
-====Supprimer un submodule====
-  * ''git submodule deinit <path_to_submodule>''
-  * ''git rm <path_to_submodule>''
-  * ''git commit-m %%"Removed submodule"%%''
-  * ''rm -rf .git/modules/<path_to_submodule>''
-[[https://gist.github.com/myusuf3/7f645819ded92bda6677#gistcomment-2650640|How effectively delete a git submodule?]] {{ :prog:git:how_effectively_delete_a_git_submodule._github_2019-10-22_13_32_38_.html |Archive du 18/07/2018 le 22/10/2019}}
-====Changer l'url/remote d'un submodule====
-<code bash>
-git submodule set-url -- <local_path> <new_url>
-</code>
-====Signer tous les commits existants====
-  git filter-branch -f --commit-filter 'git commit-tree -S "$@"' HEAD
-  git push -f
-[[https://stackoverflow.com/questions/13043357/git-sign-off-previous-commits|Git sign off previous commits?]] {{ :prog:git:git_sign_off_previous_commits_-_stack_overflow_2019-10-22_13_32_56_.html |Archive du 24/10/2012 le 22/10/2019}}
 ====Supprimer les branches locales qui ont été supprimées sur le dépôt distant====
@@ Ligne 547: / Ligne 553: @@
 git branch --merged main | grep -v '^[ *]*main$' | xargs git branch -d
 </code>
+Bien mettre à jour ''main''. Et faire un test en enlevant la commande ''xargs ...''.
 [[https://stackoverflow.com/questions/13064613/how-to-prune-local-tracking-branches-that-do-not-exist-on-remote-anymore|How to prune local tracking branches that do not exist on remote anymore?]] {{ :prog:git:git_-_how_to_prune_local_tracking_branches_that_do_not_exist_on_remote_anymore_-_stack_overflow_20_03_2023_10_21_42_.html |Archive du 25/10/2012 le 20/03/2023}}
-=====Clés publiques / privées=====
+=====Historique=====
-Pour signer les commits, il faut commencer par avoir la clé publique et privée.
+====Chercher dans le code sur l'ensemble des commits====
-====Génération de la clé====
+  git grep <regexp> $(git rev-list --all)
+Attention, cela cherche dans tous les fichiers, pas uniquement dans les modifications du commit.
-<code bash>
+====Chercher dans le code uniquement les modifications====
-gpg --full-generate-key
-</code>
-Choisir une clé ''RSA (sign only)'' de la taille maximale (4096). ''RSA'' signe plus rapidement que ''DSA'' (qui vérifie plus rapidement). Dans mon cas, ce qui m'intéresse, c'est que les commits soient signés rapidement sur ma machine.
+  git log -S"a chercher"
-====Afficher la clé publique et privée====
+====Trouver le commit qui supprime un fichier====
-<code bash>
+Il n'y a pas moyen. Mais on peut retrouver tous les commits modifiant un fichier précis.
-gpg --list-secret-keys --keyid-format LONG
+  git log --full-history -- your_file
-</code>
+Le dernier sera celui l'ayant supprimé.
-Avec ''YYYYYYYYY'' l'id de la ligne ''sec rsa4096/YYYYYYYYY''
+====Chercher une modification également dans les sous-modules====
-Pour exporter la clé publique :
+  git submodule foreach git log -S"Pattern"
+====Changer le message de tous les commit automatiquement====
+  git filter-branch -f --msg-filter 'sed "s/^git-svn-id.*$//"' -- --all
+Cela enlève toutes les lignes commençant par ''git-svn-id'' pour tous les commits ''%%-- --all%%''.
+====Annuler temporairement des modifications====
+Les modifications sont stockés sous forme d'une liste FILO.
+  * Stocke les modifications dans une zone ''nom_memoire''.
 <code bash>
-gpg --armor --export YYYYYYYYY
+git stash push -m nom_memoire fichiers
 </code>
-Pour exporter la clé privée :
+  * Restaure les modifications
 <code bash>
-gpg --export-secret-keys YYYYYYYYY > file.key
+git stash apply
+# Il est possible d'appliquer les modifications sans enlever la dernière zone mémoire.
+git stash drop
+# Ou il est possible de tout faire en même temps.
+git stash pop
 </code>
-====Configurer git====
+====Ignorer certains commits avec blame====
-Pour importer une clé privée :
+Inscrire les numéros de commit (un par ligne) dans un fichier ''.git-blame-ignore-revs''.
-<code bash>
+====Modifier une liste de commits====
-gpg --import file.key
-</code>
+Applique ''clang-format'' pour tous les fichiers ''.cpp'' ayant changés.
-Si on souhaite ajouter la signature des commits pour tous les projets.
 <code bash>
-git config --global user.signingkey YYYYYYYYY
+git filter-branch --tree-filter 'git-clang-format $(\
-git config --global commit.gpgsign true
+  git diff-index --diff-filter=AM --name-only $GIT_COMMIT |\
+    grep .cpp)' -- <SHA1>..HEAD
 </code>
-====Mettre à jour la clé====
+[[https://stackoverflow.com/questions/43974371/run-git-clang-format-on-series-of-git-commits|Run git-clang-format on series of git commits]] {{ :prog:git:formatting_-_run_git-clang-format_on_series_of_git_commits_-_stack_overflow_27_03_2023_10_03_57_.html |Archive du 15/05/2017 le 27/03/2023}}
-Il faut connaître le numéro de la clé.
+=====Subtree=====
+Les subtree utilisent les ''remote'' plutôt que les ''submodules''.
+====Ajout d'un subtree====
 <code bash>
-gpg --list-keys --keyid-format=long
+git remote add -f name url_repository
+git subtree add --prefix folder url_repository branch
 </code>
-Le numéro de la clé est celui du pub après l'algorithme (''NUMERONUMERONUEM'' ci-dessous).
+avec :
+  * ''folder'' : le dossier qui contiendra le ''subtree'',
+  * ''url_repository'' : l'url de dépôt git du ''subtree'',
+  * ''branch'' : la branch (master par exemple).
-<code>
+Dans le cas d'une architecture ''subtree'', l'historique des ''subtree'' est ajouté au super projet. Si ce n'est pas souhaité, il faut ajouter ''%%--squash%%''
-pub   rsa4096/NUMERONUMERONUEM 2020-08-09 [SC] [expires: 2022-08-11]
-      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-uid                 [ unknown] USERNAME <mail@example.com>
-sub   rsa4096/XXXXXXXXXXXXXXXX 2020-08-09 [E] [expires: 2022-08-11]   </code>
-===Date d'expiration===
+''git subtree add'' ne fonctionne que sur un dépôt ayant déjà au moins un commit.
-Pour mettre à jour la date d'expiration, il faut faire :
+====pusher un subtree====
-<code bash>
+Faire un commit de façon traditionnelle.
-gpg --edit-key KEY_ID
-list
-key 0
-expire
-key 1
-expire
-save
-</code>
-Ne pas choisir une date d'expiration supérieure à 1 an. C'est la limite de sécurité généralement considérée comme sûr.
+La technique consiste à ''pusher'' sur les dépôts distants puis à synchroniser le dépôt principal.
-Pour la mettre à jour sur GitHub, il faut supprimer la clé publique précédente avant de la rajouter. Sinon GitHub détecte que la clé publique a déjà été importée mais il ne détecte pas le changement de date.
+  git subtree push --prefix=folder remote_name branch
+Mais en faisant simplement çà, on se retrouve avec des commits différents entre le dépot principal et le dépot ''subtree''. Il faut donc les synchroniser à nouveau :
+====Récupérer les modifications d'une branche====
+  git subtree pull --prefix=folder remote_name branch
+Et c'est très moche dans l'historique de git :
+{{:prog:git:git_historique_subtree.png|Historique git avec subtree et plusieurs branches}}
+En plus, dans le ''pull'', on ne peut pas faire un commit pour deux branches distinctes.
+Je ne comprends pas pourquoi les ''subtree'' sont considérés par certains comme mieux que les submodules.
+[[https://delicious-insights.com/fr/articles/git-subtrees/|Comprendre et maîtriser les subtrees Git]] {{ :prog:git:comprendre_et_maitriser_les_subtrees_git_delicious_insights_2019-10-07_23_58_57_.html |Archive du 30/01/2015 le 07/10/2019}}
+[[https://gauthier.frama.io/post/git-subtree/|Git subtree: une alternative à Git submodule]] {{ :prog:git:git_subtree_une_alternative_a_git_submodule_le_blog_de_gauthier_2019-10-07_00_00_35_.html |Archive du 15/05/2019 le 08/10/2019}}
+[[https://tsh.io/blog/git-subtree-or-how-i-stopped-worrying-and-learned-to-love-external-dependencies/|Git subtree or how I stopped worrying and learned to love external dependencies]] {{ :prog:git:how_i_learned_to_love_external_dependencies_tsh.io_2019-11-21_10_43_04_.html |Archive du 27/11/2018 le 21/11/2019}}
+=====Best partices=====
+====Un dépôt global ou un dépôt par projet / dépendance====
+Je conseille un projet par librairie / projet.
+L'utilisation d'un projet unique impose à cloner tout, y compris des projets et dépendances dont on n'a pas besoin.
+===Nombres de dépôts===
+Séparer les dépôts réduit le nombre de dépendances de chaque projet car chaque projet n'importe que ses dépendances.
+Mais avoir de nombreux projets nécessite plus de travail pour la synchronisation et pour la publication officielles des versions.
+===Gestion des dépendances===
+  * Super projet contenant les submodules à la racine
+Exemple [[https://github.com/boostorg/boost/tree/master/libs|Boost]]. Les librairies n'ont pas de submodule.
+Inconvénients :
+  - Nécessite un super projet pour compiler. Au choix : soit un super projet qui clone tout (Boost), soit un super projet par projet à compiler.
+  - Dépendances circulaires difficilement détectables entre projets.
+  * Submodule dans chaque projet
+Inconvénients :
+  - Clonage récursif infini si dépendances circulaires.
+  - Si 2 librairies dépendent d'une même 3ème, la 3ème peut être a des versions différentes sur les 2 premières librairies.
+  * Gestionnaire externe (vcpkg)
+Inconvénients :
+  - Travail supplémentaire pour maintenir les ports vcpkg. Dans le cas de vcpkg, il faut créer un port par branche de dev et l'utiliser en mode ''%%--head%%''.
+  - Si on travaille sur des dépendances, ça oblige à commiter à chaque test et vcpkg doit tout recompiler.
+====Rebase / amend / force push====
+Faut-il autoriser les rebases ou non ? Il y a 2 parties irréconciliables : avoir un arbre git propre (et autoriser les rebases) et avoir un arbre qui mémorise l'évolution de l'écriture du code (et interdir les rebases).
+===Retravailler l'historique===
+  * Sur les branches de développement
+Je suis pour les modifications. C'est un espace de travail et de bac à sable qui peut être utilisé pour tester le code sur la CI. De plus, ça permet de sauvegarder le code quotidiennement et de voir l'état de la CI.
+⚠️ Autoriser de retravailler une branche interdit de se greffer sur une branche de développement d'un dépôt enfant. La branche de développement de l'autre dépôt peut aussi être retravaillée. On risque de se retrouver avec un historique des commits inutilisables dans la branche de developpement du dépôt parent.
+Par contre, il ne faut fusionner que les commits qui concerne une même tâche et ne pas fusionner tout l'historique (squash) pour avoir l'historique le plus petit possible.
+  * Modifier le commit de base d'une racine
+Lors d'un merge, il faut utiliser ''%%--no-ff%%'' afin de garder visuellement la branche dans l'arbre git.
+L'intérêt de modifier le commit de base est d'éviter d'avoir un arbre git qui ressemble à ça.
+{{:prog:git:git-large-tree.png?650|}}
+Mais plutôt d'avoir :
+{{:prog:git:git-thin-tree.png?427|}}
+Oui, c'est plus joli. Mais est-ce c'est nécessaire de l'imposer ?
+Si beaucoup de personnes travaillent en même temps sur le projet, l'imposer est ingérable. Peut-être l'imposer si le commit de base a plus d'une semaine / un mois par rapport au commit le plus récent dans la branche de destination ?
+S'il n'y a pas de conflit lors du merge, ne pas l'imposer.
+En cas de conflit lors du merge, il ne faut pas résoudre le conflit en local avant de merger. Sinon, la résolution des conflits seront dans le commit de merge et c'est contre-intuitif de lire le commit de merge pour lire les modifications.
+{{:prog:git:git-merge-conflict.png?808|}}
+Il faut appliquer la technique de Gitlab avec le double merge. On merge la branche de destination vers la branche de dev pour résoudre les conflits puis on merge la branche de dev vers la branche de destination. Il y a toujours un commit de merge qui contient la résolution des conflits mais il est séparé du commit de merge final.
+{{:prog:git:git-merge-conflict-2.png?419|}}
+On peut aussi faire des rebases régulièrement afin d'éviter d'avoir trop de conflits à gérer. Mais il peut être plus facile de résoudre tous les conflits en une fois.
-[[https://makandracards.com/makandra-orga/13644-what-to-do-when-your-gpg-pgp-key-expires|What to do when your GPG/PGP key expires]] {{ :prog:git:what_to_do_when_your_gpg_pgp_key_expires_-_makandra_orga_2021-08-11_20_28_16_.html |Archive du 2013 le 11/08/2021}}
 =====Messages d'erreur=====
 ====warning: unable to rmdir 'XXXX': Directory not empty====
 C'est généralement affiché lors d'un ''checkout''. Cela signifie qu'un module a été supprimé mais que git a décidé de ne pas supprimer le dossier. Il suffit de le supprimer manuellement.
 ====warning: you may want to set your XXX variable to at least YYY and retry the command.====
   git config XXX YYY
 ====git describe====
     * ''No names found, cannot describe anything''
@@ Ligne 688: / Ligne 808: @@
 Supprimer le dossier ''~/.gnupg'' et réimporter les clés privées.
-=====Windows=====
-[[https://gitforwindows.org|Site Web]], {{ :prog:git:git-2.21.0-64-bit.exe |Archive git gui 64 bit 2.21.0 (26/02/2019)}}
-[[http://matthew-brett.github.io/pydagogue/git_gui_windows.html|Getting started with git gui on Windows]] {{ :prog:git:getting_started_with_git_gui_on_windows_pydagogue_0.2_documentation_2019-10-22_13_33_19_.html |Archive le 22/10/2019}}
-=====Github=====
-====Personal access token====
-Pour pouvoir pousser sur un dépôt en utilisant un token plutôt que le mot de passe du site, il faut :
-  * Générer le token dans les [[https://github.com/settings/tokens|settings]] de l'utilisateur,
-  * Créer un nouveau token avec les droits : ''read:org'', ''repo'', ''user:email'', ''workflow '' (si le dépôt contient un dossier ''.workflow''),
-  * Noter la clé,
-  * Puis, au moment de faire un ''push'', mettre le nom d'utilisateur puis le token (pas le mot de passe de connexion de github). Il faut aussi faire attention que l'adresse de ''push'' est bien en ''https:%%//%%'' et pas en ''git:%%//%%''.
-=====Third party=====
-====Gource====
-Programme de visualisation sous forme de vidéos des dépôts github. [[https://gource.io/|Site web]] {{ :prog:gource:gource-0.51.win64.zip |Archive v0.51 x64}}
-Le dépôt est représenté sous forme d'un arbre. Le dossier est une branche et les fichiers sont des feuilles.
-Puis on voit où chaque contributeur contribue au fil du temps.
-Commandes [[https://github.com/acaudwell/Gource/wiki/Videos|Videos]] {{ :prog:gource:videos_acaudwell_gource_wiki_2020-12-28_03_20_24_.html |Archive du 21/08/2018 le 28/12/2020}}
-<code bash>
-gource -1280x720 -o gource.ppm
-ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -vcodec libx264 -preset ultrafast -pix_fmt yuv420p -crf 24 -threads 8 gource.mp4
-</code>
-Attention, l'encodage est mauvais dans les dégradés sombres. Il faudra accepter une vidéo de faible taille avec des carrés ou mettre un crf très faible (< 15) avec une vidéo de très grosse taille.