Come includere commenti di commit git?

Question

C'è un modo per inserire commenti di commit git (se visualizzati tramite git log), in modo che non siano troncati alla fine della riga? Sembra che ci dovrebbe essere una soluzione piuttosto semplice, ma non sono stato in grado di trovarne uno.

Grazie.

Answer 1

Modifica 2011: il otheranswers (con aumento) evidenzia la possibilità di modificare le opzioni less, il cercapersone predefinito utilizzato da git.
L'osservazione alla fine della mia risposta è ancora valida: anche se è possibile vedere un messaggio di commit lungo, ciò non significa che altri strumenti che hanno a che fare con detto messaggio (lungo) saranno in grado di elaborarli.

risposta

---

originale (gennaio 2010) circa commettere politica formato del messaggio:

Secondo this blog, dal momento che git log non fa alcun tipo di imballaggio, è necessario formattare il tuo commento con una lunghezza di riga appropriata

• git log non fa suo imballaggio speciale speciale dei messaggi di commit.
  Con il cercapersone predefinito di less -S, ciò significa che i paragrafi scorrono lontano dal bordo dello schermo, rendendoli difficili da leggere.
  Su un terminale a 80 colonne, se sottraiamo 4 colonne per il rientro a sinistra e altre 4 per la simmetria a destra, rimaniamo con 72 colonne.
• git format-patch --stdout converte una serie di commit in una serie di e-mail, utilizzando i messaggi per il corpo del messaggio.
  Una buona e-mail di netiquette ci impone di avvolgere le nostre e-mail di testo in modo tale che ci sia spazio per alcuni livelli di indicatori di risposta annidati senza overflow in un terminale a 80 colonne.

Come said here:

In generale, utilizzare un editor per creare i messaggi di commit piuttosto che passare sulla riga di comando. Il formato deve essere:

• Un involucro rigido a 72 caratteri
• Un'unica breve riassunto del commit
• seguita da una sola riga vuota
• Seguito da dettagli di supporto

---

Tutte le origini (incluso GitPro book, che va per 50 caratteri per la prima riga, come Jörg W Mittag commenti) insistere sulla necessità di avvolgere il commento, certamente perché, anche se Git è stato in grado di gestire lunghe code, altri strumenti nella catena di elaborazione (e-mail, patch, ...) potrebbero non .

Answer 2

Nella risposta precedente viene menzionato che il pager predefinito (spesso "meno") è responsabile del wrapping e, di default, in genere riduce le righe lunghe.

Per modificare questo senza cambiare i tuoi messaggi commit (esempio di meno e bash):

$ echo $LESS 
-FRSX 

Questo era quello che avevo per impostazione predefinita, ormai per sovrascrivere la variabile d'ambiente LESS.

echo "LESS=-FRX;export LESS" >> ~/.bash_profile 
source ~/.bash_profile 

Answer 3

Oppure si può cambiare il tuo cercapersone per usare less -R

$ git config --global core.pager 'less -R' 

questo vi dirà meno di smettere di cercare di controllare come lo schermo è formattato (normalmente è possibile scorrere a destra ea sinistra nel corso di una git log utilizzando freccia chiavi). E come dice il manuale in meno "In questo modo, possono verificarsi diversi problemi di visualizzazione, ad esempio se le righe lunghe vengono scomposte nel posto sbagliato." Quale è quello che vuoi, vuoi che la linea finisca per apparire alla destra del tuo schermo (il posto sbagliato) invece di dove l'autore del commento lo mise.

Inoltre, premendo il tasto freccia senza modificare il cercapersone, è possibile visualizzare più codice. Qual è il mio metodo preferito.

Answer 4

Non sembra che ci sia un modo perfetto. Una soluzione che uso è solo per inviare l'output a more (o less, o cat ecc):

git log | more 

che avvolge le lunghe file, almeno sul mio sistema (tuttavia, si perde la formattazione del colore).

Answer 5

Almeno in git versione 1.7.9.5, git log fa avvolgimento linea di supporto. Da git aiuto di registro:

PRETTY FORMATS 
    %w([<w>[,<i1>[,<i2>]]]): switch line wrapping 

Così, per esempio, il seguente avvolge i soggetti lunghi a 72 colonne:.

alias gl='git log --format="%C(yellow)%h %an %ad%C(reset)%n%w(72,1,2)%s"' 

(convenuto che commettono convenzioni di formattazione dovrebbero essere seguite invece di basarsi su questo Tuttavia , questo potrebbe rivelarsi utile fino al giorno in cui tutti conoscono e rispettano le convenzioni.)

Answer 6

Nota che meno -r (come consigliato sopra) porta a dimenticare meno il conteggio delle righe e ti perdi perché le tue righe più in alto scorreranno fuori di vista! La vera difficoltà è la disabilitazione l'opzione -S che Git abilita per impostazione predefinita se la variabile d'ambiente LESS non è impostata.

Una buona correzione sta cambiando la vostra configurazione git nel seguente modo:

git config --global core.pager 'less -+S'

Answer 7

Questo mi ha aiutato.

git --no-pager log WhateverBranch | head -n40 

In genere il ramo è grande, quindi, tubazioni è a capo e con l'interruttore -n consente di catturare solo il più recente 40 (o comunque molti) le linee di uscita che è necessario, e dovrebbe avvolgere (non c'è bisogno di scorrere). Essere consapevoli di questo approccio manca anche la formattazione del colore.

Answer 8

Come accennato VonC, si consiglia di avvolgere i messaggi di commit a 72 caratteri e uccidere molti piccioni con una fava.Questo gancio git auto-avvolge i messaggi di commit e funziona con qualsiasi editor: https://github.com/surabhigupta/AutoWrapSeventyTwo

Answer 9

utilizzo di questo formato ha reso la mia vita più felice:

log --pretty=format:\"%w(80,1,41)%h - %an, %ar : %s\" 

Dal momento che i campi nell'output in vista del messaggio di commit è pari a circa 39 caratteri per la maggior parte dei miei commit, rende la lettura molto più facile.

Answer 10

La suggestione personale è semplice. Quando vuoi vedere le linee complete nel meno cercapersone digita semplicemente -S questo cambierà a piegare le linee o indietro se vuoi vedere una sezione in questo modo.

Answer 11

Se nano è l'editor preferito, è possibile impostare git per utilizzare nano con il wrapping automatico ad es. 72 caratteri:

git config --global core.editor "nano -r 72" 

Answer 12

Per coloro che utilizzano SourceTree, c'è un ambiente (Opzioni> Generale) che mostrerà una guida colonna nel messaggio di commit:

Answer 13

Quindi stavo cercando una soluzione a un problema simile a questo, e mi sono imbattuto in questa domanda. Nel mio caso sto eseguendo git show e ho 2 righe in cui il cambiamento è in una parola, verso la fine di una linea molto lunga. Ho finito per risolvere questo problema con un approccio simile a quello che faccio con git diff, usando l'opzione --word-diff-regex.

git show --color --word-diff-regex="[^[:space:],]+" 55de9c954d5d74a185879d3441a69cc1889c00f1 |more

Answer 14

Ecco come ho risolto per il confezionamento di messaggi di log git, per coloro che sono ancora alla ricerca di risposte:

git log --pretty=format:"@%H,%cn,%cD,%B" <file name> | tr "\n" " "|tr "@" "\n" 

L'output del comando git log viene convogliato che trova il ritorno a capo e sostituisce con uno spazio bianco. Questa è la logica utilizzata per unire i messaggi di commit come una singola riga.

Qui, sto usando "@" come delimitatore per differenziare tra i commit. Puoi sostituirlo con qualunque simbolo speciale desideri. "% H" rappresenta l'hash del commit, "% cn" rappresenta il nome del committer, "% cD" rappresenta la data del commit e il messaggio del corpo grezzo "% B". Se volete saperne di più su pretty = format, date un'occhiata a https://git-scm.com/docs/pretty-formats

Si prega di notare che questo potrebbe non funzionare se si dispone di carattere di nuova riga all'interno del messaggio di commit git.

Answer 15

BREVE RISPOSTA:
Tipo -S poi Inserisci durante la visualizzazione del registro git.

risposta dettagliata:
git log uscite tramite il visualizzatore less testo, così semplicemente digitare -S quindi Invio per commutare tra le due modalità linea di incarto di "Chop linee lunghe" e "linee di piegatura lunghe." L'opzione "Piega righe lunghe" abilita il ritorno a capo automatico.

Fonte che mi ha aiutato a imparare questo: https://superuser.com/a/272826/425838