Réponses:
xargs
fera ce que vous voulez:
git ls-files | xargs cat | wc -l
Mais avec plus d'informations et probablement mieux, vous pouvez faire:
git ls-files | xargs wc -l
grep cpp |
y avant le xargs
, alors.
git ls-files -z | xargs -0 wc -l
si vous avez des fichiers avec des espaces dans le nom.
git ls-files | grep -P ".*(hpp|cpp)" | xargs wc -l
où la partie grep est toute expression rationnelle de perl que vous voulez!
git ls-files | grep "\.java$" | xargs wc -l
git diff --stat 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Cela montre les différences entre l'arborescence vide et votre arborescence de travail actuelle. Ce qui arrive à compter toutes les lignes de votre arbre de travail actuel.
Pour obtenir les nombres dans votre arborescence de travail actuelle, procédez comme suit:
git diff --shortstat `git hash-object -t tree /dev/null`
Cela vous donnera une chaîne comme 1770 files changed, 166776 insertions(+)
.
git hash-object -t tree /dev/null
.
git diff --stat `git hash-object -t tree /dev/null`
git diff --stat `git hash-object -t tree /dev/null` | tail -1
git diff --shortstat `git hash-object -t tree /dev/null`
pour obtenir la dernière ligne, la queue n'est pas nécessaire.
Si vous voulez ce compte parce que vous voulez avoir une idée de la portée du projet, vous pouvez préférer la sortie de CLOC («Count Lines of Code»), qui vous donne une ventilation des lignes de code significatives et insignifiantes par langue.
cloc $(git ls-files)
(Cette ligne est équivalente à git ls-files | xargs cloc
. Elle utilise sh
la fonction de $()
substitution de commandes de .)
Exemple de sortie:
20 text files.
20 unique files.
6 files ignored.
http://cloc.sourceforge.net v 1.62 T=0.22 s (62.5 files/s, 2771.2 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Javascript 2 13 111 309
JSON 3 0 0 58
HTML 2 7 12 50
Handlebars 2 0 0 37
CoffeeScript 4 1 4 12
SASS 1 1 1 5
-------------------------------------------------------------------------------
SUM: 14 22 128 471
-------------------------------------------------------------------------------
Vous devrez d'abord installer CLOC. Vous pouvez probablement installer cloc
avec votre gestionnaire de paquets - par exemple, brew install cloc
avec Homebrew .
cloc $(git ls-files)
est souvent une amélioration cloc .
. Par exemple, l'exemple de sortie ci-dessus avec git ls-files
471 lignes de code de rapport. Pour le même projet, cloc .
signale un énorme 456 279 lignes (et prend six minutes pour s'exécuter), car il recherche les dépendances dans le node_modules
dossier ignoré par Git .
cloc --vcs git
ces jours-ci, ce qui évite certains cas marginaux avec des fichiers mal nommés (ou trop nombreux).
J'ai rencontré des problèmes de git ls-files | xargs wc -l
traitement par lots lors du traitement d'un grand nombre de fichiers, où le nombre de lignes est divisé en plusieurs total
lignes.
Prendre un conseil à la question Pourquoi l'utilitaire wc génère-t-il plusieurs lignes avec "total"? , J'ai trouvé la commande suivante pour contourner le problème:
wc -l $(git ls-files)
Ou si vous souhaitez examiner uniquement certains fichiers, par exemple le code:
wc -l $(git ls-files | grep '.*\.cs')
wc -l $(git ls-files | find *.m *.h)
wc -l --files0-from=<(git ls-files -z)
. La <(COMMAND)
syntaxe renvoie le nom d'un fichier dont le contenu est le résultat de COMMAND
.
La meilleure solution, pour moi en tout cas, est enterrée dans les commentaires de la réponse de @ ephemient. Je le tire juste ici pour qu'il ne passe pas inaperçu. Le mérite en revient à @FRoZeN (et @ephemient).
git diff --shortstat `git hash-object -t tree /dev/null`
renvoie le total des fichiers et des lignes dans le répertoire de travail d'un dépôt, sans aucun bruit supplémentaire. En prime, seul le code source est compté - les fichiers binaires sont exclus du décompte.
La commande ci-dessus fonctionne sous Linux et OS X. La version multiplateforme de celle-ci est
git diff --shortstat 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Cela fonctionne aussi sur Windows.
Pour mémoire, les options pour exclure les lignes vides,
-w
/ --ignore-all-space
,-b
/ --ignore-space-change
,--ignore-blank-lines
, --ignore-space-at-eol
n'ont aucun effet lorsqu'il est utilisé avec --shortstat
. Les lignes vides sont comptées.
git mktree </dev/null
ou true|git mktree
ou git mktree <&-
ou :|git mktree
pour les compteurs de touches parmi nous :-) - un arbre vide de rechange flottant autour du dépôt ne va rien faire de mal.
Cela fonctionne à partir du cloc 1.68:
cloc --vcs=git
--vcs
n'a pas fonctionné pour moi, peut-être qu'il a été supprimé. cloc .
tandis qu'au git repo a fonctionné, OTOH.
Je jouais avec cmder ( http://gooseberrycreative.com/cmder/ ) et je voulais compter les lignes html, css, java et javascript. Alors que certaines des réponses ci-dessus fonctionnaient, le or
modèle dans grep ne fonctionnait pas - j'ai trouvé ici ( /unix/37313/how-do-i-grep-for-multiple-patterns ) que j'avais pour y échapper
Voici donc ce que j'utilise maintenant:
git ls-files | grep "\(.html\|.css\|.js\|.java\)$" | xargs wc -l
J'utilise ce qui suit:
git grep ^ | wc -l
Cela recherche tous les fichiers versionnés par git pour l'expression régulière ^
, qui représente le début d'une ligne, donc cette commande donne le nombre total de lignes!
J'ai fait ça:
git ls-files | xargs file | grep "ASCII" | cut -d : -f 1 | xargs wc -l
cela fonctionne si vous comptez tous les fichiers texte du référentiel comme fichiers d'intérêt. Si certains sont considérés comme de la documentation, etc., un filtre d'exclusion peut être ajouté.
Cet outil sur github https://github.com/flosse/sloc peut donner la sortie de manière plus descriptive. Il créera des statistiques de votre code source:
: | git mktree | git diff --shortstat --stdin
Ou:
git ls-tree @ | sed '1i\\' | git mktree --batch | xargs | git diff-tree --shortstat --stdin
Selon que vous souhaitez ou non inclure des fichiers binaires, il existe deux solutions.
git grep --cached -al '' | xargs -P 4 cat | wc -l
git grep --cached -Il '' | xargs -P 4 cat | wc -l
"xargs -P 4" signifie qu'il peut lire les fichiers en utilisant quatre processus parallèles. Cela peut être très utile si vous analysez de très grands référentiels. Selon la capacité de la machine, vous pouvez augmenter le nombre de processus.
-a, traite les fichiers binaires sous forme de texte (Inclure les binaires)
-l '', affiche uniquement les noms de fichiers au lieu des lignes correspondantes (Analyse uniquement les fichiers non vides)
-I, ne correspond pas aux modèles des fichiers binaires (Exclure les binaires)
--cached, rechercher dans l'index plutôt que dans l'arborescence de travail (inclure les fichiers non validés)