Risposte:
xargs farà quello che vuoi:
git ls-files | xargs cat | wc -lMa con più informazioni e probabilmente meglio, puoi fare:
git ls-files | xargs wc -lgrep cpp |prima del xargs, quindi.
git ls-files -z | xargs -0 wc -lse si hanno file con spazi nel nome.
git ls-files | grep -P ".*(hpp|cpp)" | xargs wc -ldove la parte grep è qualsiasi regex perl che vuoi!
git ls-files | grep "\.java$" | xargs wc -l
git diff --stat 4b825dc642cb6eb9a060e54bf8d69288fbee4904Questo mostra le differenze dall'albero vuoto al tuo attuale albero di lavoro. Che succede a contare tutte le linee nel tuo attuale albero di lavoro.
Per ottenere i numeri nel tuo attuale albero di lavoro, procedi come segue:
git diff --shortstat `git hash-object -t tree /dev/null`Ti darà una stringa come 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` per ottenere l'ultima riga, la coda non è necessaria.
Se si desidera questo conteggio perché si desidera avere un'idea dell'ambito del progetto, è possibile preferire l'output di CLOC ("Count Lines of Code"), che fornisce una suddivisione di righe di codice significative e insignificanti per lingua.
cloc $(git ls-files)(Questa riga equivale a git ls-files | xargs cloc. Usa shla $()sostituzione di comando funzione di .)
Uscita campione:
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
-------------------------------------------------------------------------------Dovrai prima installare CLOC. Probabilmente puoi installarlo cloccon il tuo gestore pacchetti, ad esempio brew install cloccon Homebrew .
cloc $(git ls-files)è spesso un miglioramento cloc .. Ad esempio, l'output di esempio sopra git ls-filesriportato riporta 471 righe di codice. Per lo stesso progetto, cloc .riporta 456.279 righe (e richiede sei minuti per l'esecuzione), perché cerca le dipendenze nella node_modulescartella ignorata da Git .
cloc --vcs gitquesti giorni, il che evita alcuni casi limite con file con nomi errati (o troppi di essi).
Ho riscontrato problemi di batch con git ls-files | xargs wc -lquando si ha a che fare con un numero elevato di file, in cui i conteggi delle righe verranno suddivisi in più totalrighe.
Prendere una mancia dalla domanda Perché l'utilità wc genera più righe con "totale"? , Ho trovato il seguente comando per aggirare il problema:
wc -l $(git ls-files)
O se si desidera esaminare solo alcuni file, ad esempio il codice:
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)sintassi restituisce il nome di un file il cui contenuto è il risultato diCOMMAND .
La soluzione migliore, secondo me, è sepolta nei commenti della risposta di @ephemient. Lo sto solo tirando su qui in modo che non passi inosservato. Il merito per questo dovrebbe andare a @FRoZeN (e @ephemient).
git diff --shortstat `git hash-object -t tree /dev/null`restituisce il totale di file e linee nella directory di lavoro di un repository, senza alcun rumore aggiuntivo. Come bonus, viene conteggiato solo il codice sorgente - i file binari sono esclusi dal conteggio.
Il comando sopra funziona su Linux e OS X. La versione multipiattaforma è
git diff --shortstat 4b825dc642cb6eb9a060e54bf8d69288fbee4904Funziona anche su Windows.
Per la cronaca, le opzioni per escludere le righe vuote,
-w/ --ignore-all-space,-b/ --ignore-space-change,--ignore-blank-lines, --ignore-space-at-eolnon ha alcun effetto se usato con --shortstat . Vengono contate le righe vuote.
git mktree </dev/nullo true|git mktreeo git mktree <&-o :|git mktreeper i contatori di tasti tra noi :-) - un albero vuoto di riserva che galleggia intorno al repository non farà male a nulla.
Funziona a partire da cloc 1.68:
cloc --vcs=git
--vcsnon ha funzionato per me, forse è stato rimosso. cloc .mentre al repository git ha funzionato, OTOH.
Stavo giocando con cmder ( http://gooseberrycreative.com/cmder/ ) e volevo contare le righe di html, css, java e javascript. Mentre alcune delle risposte sopra hanno funzionato, lo orschema in grep non ha funzionato - ho trovato qui ( /unix/37313/how-do-i-grep-for-multiple-patterns ) che avevo per sfuggire
Quindi questo è quello che uso ora:
git ls-files | grep "\(.html\|.css\|.js\|.java\)$" | xargs wc -l
Io uso il seguente:
git grep ^ | wc -lQuesto cerca in tutti i file controllati da git il regex ^, che rappresenta l'inizio di una riga, quindi questo comando fornisce il numero totale di righe!
L'ho fatto:
git ls-files | xargs file | grep "ASCII" | cut -d : -f 1 | xargs wc -lfunziona se si contano tutti i file di testo nel repository come file di interesse. Se alcuni sono considerati documentazione, ecc., È possibile aggiungere un filtro di esclusione.
Questo strumento su github https://github.com/flosse/sloc può fornire l'output in modo più descrittivo. Creerà le statistiche del tuo codice sorgente:
: | git mktree | git diff --shortstat --stdinO:
git ls-tree @ | sed '1i\\' | git mktree --batch | xargs | git diff-tree --shortstat --stdinA seconda che tu voglia o meno includere file binari, ci sono due soluzioni.
git grep --cached -al '' | xargs -P 4 cat | wc -lgit grep --cached -Il '' | xargs -P 4 cat | wc -l
"xargs -P 4" significa che può leggere i file usando quattro processi paralleli. Questo può essere davvero utile se stai eseguendo la scansione di repository di grandi dimensioni. A seconda della capacità della macchina è possibile aumentare il numero di processi.
-a, elabora i file binari come testo (Includi binari)
-l '', mostra solo i nomi dei file anziché le righe corrispondenti (Scansiona solo i file non vuoti)
-I, non corrisponde ai pattern nei file binari (Escludi binario) -
cache, cerca nell'indice anziché nell'albero di lavoro (Includi file non registrati)