Il est implémenté maintenant (git 1.9 / 2.0, Q1 2014) avec l'introduction pathspec magic :(exclude)
et sa forme courte:!
dans commit ef79b1f et commit 1649612 , par
Nguyễn Thái Ngọc Duy ( pclouds
) , la documentation peut être trouvée ici .
Vous pouvez maintenant tout consigner sauf le contenu d'un sous-dossier:
git log -- . ":(exclude)sub"
git log -- . ":!sub"
Ou vous pouvez exclure des éléments spécifiques dans ce sous-dossier
un fichier spécifique:
git log -- . ":(exclude)sub/sub/file"
git log -- . ":!sub/sub/file"
tout fichier donné dans sub
:
git log -- . ":(exclude)sub/*file"
git log -- . ":!sub/*file"
git log -- . ":(exclude,glob)sub/*/file"
Vous pouvez rendre cette exclusion insensible à la casse!
git log -- . ":(exclude,icase)SUB"
Comme l'a noté Kenny Evitt
Si vous exécutez Git dans un shell Bash, utilisez ':!sub'
ou à la ":\!sub"
place pour éviter les bash: ... event not found
erreurs
Remarque: Git 2.13 (Q2 2017) ajoutera un synonyme ^
à!
Voir commit 859b7f1 , commit 42ebeb9 (08 février 2017) par Linus Torvalds ( torvalds
) .
(Fusionné par Junio C Hamano - gitster
- in commit 015fba3 , 27 fév 2017)
pathspec magic: ajoutez « ^
» comme alias pour « !
»
Le choix de ' !
' pour un pathspec négatif finit non seulement par ne pas correspondre à ce que nous faisons pour les révisions, mais c'est aussi un caractère horrible pour l'expansion du shell car il doit être cité.
Ajoutez donc « ^
» comme alias alternatif pour une entrée de spécification de chemin d'exclusion.
Notez qu'avant Git 2.28 (T3 2020), l'utilisation de pathspec négative, lors de la collecte des chemins, y compris ceux non suivis dans l'arbre de travail, était interrompue.
Voir commit f1f061e (05 juin 2020) par Elijah Newren ( newren
) .
(Fusionné par Junio C Hamano - gitster
- dans commit 64efa11 , 18 juin 2020)
dir
: correction du traitement des pathspecs annulés
Signalé par: John Millikin
Signature par: Elijah Newren
do_match_pathspec()
a commencé la vie au fur match_pathspec_depth_1()
et à mesure que l'exactitude était censée être appelée match_pathspec_depth()
. match_pathspec_depth()
a été renommé plus tard en match_pathspec()
, donc l'invariant auquel nous nous attendons aujourd'hui est qu'il do_match_pathspec()
n'y a aucun appelant direct en dehors de match_pathspec()
.
Malheureusement, cette intention a été perdue avec le renommage des deux fonctions, et des appels supplémentaires à do_match_pathspec()
ont été ajoutés dans les commits 75a6315f74 (" ls-files
: add pathspec matching for submodules", 2016-10-07, Git v2.11.0-rc0 - merge listée dans batch # 11 ) et 89a1f4aaf7 (" dir
: si notre spécification de chemin peut correspondre à des fichiers sous un répertoire, recurse dedans", 17/09/2019, Git v2.24.0-rc0).
Bien sûr, do_match_pathspec()
avait un avantage important par rapport à match_pathspec()
- match_pathspec()
coder en dur les indicateurs à l'une des deux valeurs, et ces nouveaux appelants devaient passer une autre valeur pour les indicateurs.
De plus, bien que l'appel do_match_pathspec()
direct soit incorrect, il n'y avait probablement aucune différence dans la sortie de fin observable, car le bogue signifiait simplement que cela fill_diretory()
se répéterait dans des répertoires inutiles.
Étant donné que les vérifications ultérieures de la correspondance de ce chemin sur les chemins individuels sous le répertoire entraîneraient le filtrage de ces chemins supplémentaires, la seule différence par rapport à l'utilisation de la mauvaise fonction était un calcul inutile.
Le deuxième de ces mauvais appels à do_match_pathspec()
était impliqué - soit via un mouvement direct ou via la copie + édition - dans un certain nombre de refactors ultérieurs.
Voir commits 777b420347 (" dir
: synchronize treat_leading_path()
and read_directory_recursive()
", 2019-12-19, Git v2.25.0-rc0 - merge ), 8d92fb2927 (" dir
: replace l'algorithme exponentiel par un linéaire", 2020-04-01, Git v2.27.0 -rc0 - fusion répertoriée dans le lot n ° 5 ) et 95c11ecc73 ("Correction de l' fill_directory()
API sujette aux erreurs ; ne renvoyer que les correspondances", 2020-04-01, Git v2.27.0-rc0 - fusion répertoriée dans le lot n ° 5 ) .
Le dernier de ceux-ci a introduit l'utilisation de do_match_pathspec()
sur un fichier individuel, et a donc entraîné le retour de chemins individuels qui ne devraient pas l'être.
Le problème avec l' appel au do_match_pathspec()
lieu de match_pathspec()
est que tous les modèles niées comme « `: unwanted_path`` seront ignorés .
Ajoutez une nouvelle match_pathspec_with_flags()
fonction pour répondre aux besoins de spécification d'indicateurs spéciaux tout en vérifiant correctement les modèles annulés, ajoutez un gros commentaire ci-dessus do_match_pathspec()
pour empêcher les autres de l'utiliser à mauvais do_match_pathspec()
escient et corrigez les appelants actuels de pour utiliser à la place soit match_pathspec()
ou match_pathspec_with_flags()
.
Une dernière remarque est que cela DO_MATCH_LEADING_PATHSPEC
nécessite une attention particulière lors de l'utilisation DO_MATCH_EXCLUDE
.
Le point de DO_MATCH_LEADING_PATHSPEC
est que si nous avons un pathspec comme
*/Makefile
et nous vérifions un chemin de répertoire comme
src/module/component
que nous voulons le considérer comme une correspondance afin que nous rentrions dans le répertoire car il _might
_ a un fichier nommé Makefile
quelque part ci-dessous.
Cependant, lorsque nous utilisons un modèle d'exclusion, c'est-à-dire que nous avons une spécification de chemin comme
:(exclude)*/Makefile
nous ne voulons PAS dire qu'un chemin de répertoire comme
src/module/component
est une correspondance (négative).
Bien qu'il puisse y avoir un fichier nommé 'Makefile' quelque part sous ce répertoire, il peut également y avoir d'autres fichiers et nous ne pouvons pas exclure de manière préventive tous les fichiers de ce répertoire; nous devons récurer puis vérifier les fichiers individuels.
Ajustez la DO_MATCH_LEADING_PATHSPEC
logique pour ne s'activer que pour les pathspecs positifs.
!f() { git log ... | path/to/filter-log.pl "$@" | git log --stdin --no-walk; f
, ou même encapsuler cette partie de pipeline dans le script.