Antichesse (o ^ω^ o)
Dans votre fichier ~/.cargo/config.toml ajouter la configuration suivante
[registry]
default = "gitea"
[registries.gitea]
index = "https://mycompany.com/gitea/my-rust-repository.git"
[net]
git-fetch-with-cli = trueN.B : Je publie cette configuration ici mais je ne l'ai pas encore testée.
En une ligne :
git commit --amend --date=now
Merci @duraffort pour le lien
Merci Oros !
En plusieurs commandes en fonction des cas :
1) Tout cracher en une seule fois
git --no-pager log --pretty=tformat:"%C(yellow)%h %C(cyan)%ad %Cblue%an%C(auto)%d %Creset%s" --graph --date=format:"%Y-%m-%d %H:%M"2) Avec pagination et le graphe des merges
git log --pretty=tformat:"%C(yellow)%h %C(cyan)%ad %Cblue%an%C(auto)%d %Creset%s" --graph --date=format:"%Y-%m-%d %H:%M"3) Juste ce qu'il faut
git log --pretty=tformat:"%C(yellow)%h %C(cyan)%ad %Cblue%an%C(auto)%d %Creset%s" --date=format:"%Y-%m-%d %H:%M"En un oneliner :
git stash -- $(git diff --staged --name-only)Pour faire le diff entre deux branches :
# Diff entre le HEAD des deux branches
git diff master..ma-branch
# Diff entre le point de bifurcation de "ma-branch" dans master et le HEAD de "ma-branche"
git diff master...ma-branchEn étape (4) j'aurai réécrit l'historique de la branche sur la branche elle-même en faisant git push --force origin ma-branche à la place de git push --force origin master.
Cela a plusieurs avantages :
1) Je ne force pas la réécriture du master à chaque fois, ce qui obligerait tout le monde à mettre à jour son HEAD si des merges sont fréquents de cette branche vers lui.
2) Cela permet encore d'effectuer une PR/MR pour une review de code.
3) Cela permet de travailler sur la branche sans perturber les autres.
4) Je peux rebase ma branche autant de fois que nécessaire sans impact sur master.
Je le note pour @Kysofer qui doit gérer une PIC.
Si vos requêtes de push/pull/clone sont trop grosses et que Git vous affiche une erreur du type Github Push Error: RPC failed; result=22, HTTP code = 413 alors vous avez probablement deux choses à faire :
1) Augmenter la taille du buffer côté Git.
J'ai fixé la valeur à 1 Gio, car tous mes PC ont au moins 8 Go de RAM et tournent sous Linux. À noter que cela a grandement accéléré mes requêtes de pull/push/clone (je suis passée de 4 Mo/sec à 25 Mo/sec) :
git config --global http.postBuffer 10737418242) Augmenter la taille du cache côté Nginx s'il est en front à votre serveur Git (Gitea chez moi).
client_max_body_size 512m;Et ne pas oublier de redémarrer Nginx via un systemctl restart nginx.
Très pratique pour nettoyer toutes les feature branches récupérées au fil du temps. Bref, le nettoyage se fait en deux commandes :
# Récupérer de tout le contenu distant (hors tags)
git pull --all
# Suppression des branches locales
git remote update origin --prune
Une fois encore, GitLab explique en quoi GitFlow est over-engineered pour rien (mais certains aiment créer des branches).
J'ai pris le temps de lire les commentaires et j'ai tout de même appris une chose : je n'embaucherai pas messieurs Mark Norton, Darrell Tunnell et Abdoulaye Siby car ils n'argumentent pas, ils ne font que donner leur ressenti personnel, ressenti fondé sur des habitudes pluriannuelles qui les ont déformés.
Du reste, GitFlow étant déjà aux toilettes depuis un bon moment me concernant, je vais m’empresser de tirer la chasse au cas où il ne soit toujours pas parti.
Et merci à Philou pour le troll lien.
Des add-ons pour booster votre install Git. Merci @Philou pour le lien.
Alors ça c'est typiquement le genre de trucs que je poste pour @Philou à présent ! Rien que la syntaxe fait penser à mon bien aimé Mercurial 😍.
Via Riduidel.
Sûrement l'un des meilleurs message de commit au monde. Non pas parce que le ratio code/message est complètement barré mais parce qu'il explique pourquoi ce commit existe et non pas ce qu'il a modifié. Dit autrement, avec un moteur de recherche qui taperait dans les logs, chaque répo Git deviendrait une base de connaissance équivalente à StackOverflow.
Et Epstein ne s'est pas tué lui-même dans sa cellule #Epstein.
Coudifié ! Tout est dans le titre.
Le concept du Test, Commit, Revert (TCR) est sympa.
Comment notre façon de programmer est-elle devenue asynchrone et bloquante ? C'est vrai que je passe mon temps à revenir sur des pull-requests qui ont eu lieu plusieurs jours auparavant ; et c'est dur à chaque fois ! J'aime coder et oublier le code que je viens de coder aussitôt que la PR part. Je n'aime pas qu'on me relance sur un sujet que j'ai fermé car c'est une charge cognitive forte et épuisante et pourtant ce modèle est devenu le modèle "standard".
=> Pour @Chlouchloutte
Via Riduidel
Parce que je ne m'en souviens jamais de la commande magique : git rebase -i HEAD~X
où X et le nombre de commits à fusionner depuis le HEAD (HEAD inclus)
Puis penser à remplacer de bas en haut les pick des lignes du début par des squash (tout ce qui est squash sera fusionné avec le commit de la ligne au-dessus).
Pour toi @Philou ! Ce peut être intéressant de surveiller certains fichiers sensibles de nos répos (je pense via notre GitBot) afin de détecter des commits dessus.
Le script à mettre dans .git/hooks/post-merge
#!/usr/bin/env bash
# On met ici tous les fichiers (ou pattern de nom) qu'on veut surveiller
# changez les pour les adapter à votre projet
files=('settings.py' 'migrations');
# on récupère tous les noms de fichiers modifiés depuis le dernier merge
modified_files=`git diff "HEAD@{1}" --name-only`
# on boucle sur chaque nom de fichier surveillé
for watched_file in "${files[@]}"; do
# on liste tous les fichiers modifiés qui correspondent à ce nom de
# fichier surveillé
modified_watched_files=(`echo "$modified_files" | grep $watched_file`)
# si le nombre de fichiers correspondant est plus grand que 0
if [ ${#modified_watched_files[@]} ]; then
# pour chaque fichier qui correspond, on affiche un avertissement
# en rouge
for modified_watched_file in "${modified_watched_files[@]}"; do
echo -e "\e[41m "$modified_watched_file" has changed \033[0m"
done
fi
done
Je copie colle ici :
#!/usr/bin/env bash
set -o errexit
# Author: David Underhill
# Script to permanently delete files/folders from your git repository. To use
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-remove-history path1 path2
#
# retrieved from: http://dound.com/2009/04/git-forever-remove-files-or-folders-from-history/
#
if [ $# -eq 0 ]; then
exit 0are still
fi
# make sure we're at the root of git repo
if [ ! -d .git ]; then
echo "Error: must run this script from the root of a git repository"
exit 1
fi
# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD
# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all && git gc --aggressive --prune
J'oublie tout le temps la manipe :
git checkout #hashLast
git reset --soft #hashFirst
git commit --amend -m '1 2 3 4 5'
git rebase HEAD master