git: nuova riga vuota a EOF

Question

Quindi eseguo git diff --check prima dei file add -ing e commit -in li, e su due file specifici ottengo path/filename:linenumber: new blank line at EOF. Se elimino l'ultima riga vuota in quei file, non ricevo alcun messaggio, ma penso che sia un buon stile terminare i miei file con una nuova riga. Stranamente, gli altri file che penso abbiano esattamente lo stesso finale, non danno alcun messaggio. Sono nuovo di git, usando git 2.0.1 su OS X Yosemite. Io uso vim come mio editore.

Come posso terminare con myline i miei file evitando questo messaggio? Dovrei ignorarlo?

Answer 1

Ci sono due problemi, qui.

• si sono confusi su "a capo" vs "nuova linea":

  A "nuova linea" è una linea attuale vuota (contiene solo un carattere "a capo") e un "a capo" è un carattere speciale utilizzato per contrassegnare alla fine della riga corrente.

  La maggior parte dei compilatori, interpreti e strumenti Unix si aspetta che i file di testo finiscano con una newline per evitare ambiguità quando si gestiscono più file, non una "nuova linea".

  La maggior parte degli editori, incluso Vim, aggiunge quel carattere necessario alla fine di ogni riga, l'ultima riga inclusa, quindi non c'è niente da fare dalla tua parte per garantire che il requisito sia soddisfatto.

  Soprattutto non aggiungere una "nuova linea" all'EOF.

• probabilmente siete abituati a cattivo comportamento:

  Il carattere "a capo" è tradizionalmente interpretato come una "linea di terminazione" di strumenti Unix, la maggior parte dei compilatori e Vim. Ciò significa che qualsiasi cosa viene dopo che quel personaggio è considerato su un'altra linea. Poiché quel carattere è l'ultimo nel file, non c'è motivo di mostrare una linea che non è lì per l'utente.

  Purtroppo la maggior parte degli editor della GUI la interpretano come un "separatore di riga", ovvero segna la separazione tra due righe e in genere gli editor mostrano una riga non esistente alla fine del file per soddisfare tale interpretazione.

  Probabilmente sto assumendo troppo, ma sembra che tu sia abituato a quel comportamento sbagliato e prova a imitarlo aggiungendo una "nuova linea" totalmente inutile alla fine dei tuoi file.

O si continuare ad aggiungere "nuove linee" nella parte inferiore del vostro file di origine, ritengono che come una sorta di formattazione e linee guida di codifica e smettere di considerare quei messaggi Git i messaggi di errore.

Oppure smetti di aggiungere quelle "nuove linee" inutili.

Vorrei andare con la seconda opzione.

Answer 2

Dal git diff documentation:

--check

Avvisa se le modifiche introducono errori spazi bianchi.Gli errori degli spazi bianchi considerati sono controllati dalla configurazione core.whitespace. Per impostazione predefinita, gli spazi vuoti finali (comprese le righe costituite esclusivamente da spazi bianchi) e uno spazio che è immediatamente seguito da un carattere di tabulazione all'interno del rientro iniziale della riga sono considerati errori di spazi bianchi. Esce con stato diverso da zero in caso di problemi. Non compatibile con --exit-code.

Corrispondentemente, il git config documentation:

core.whitespace

virgole elenco dei problemi comuni spazio bianco separato notare. git diff userà color.diff.whitespace per evidenziarli e git apply --whitespace = error li considererà come errori. È possibile anteporre - disattivare uno di essi (ad esempio -trailing-space):

• blank-at-eol tratta trascinamento spazi bianchi alla fine della riga come un errore (abilitato per default).

• space-before-tab considera un carattere di spazio che viene visualizzato immediatamente prima di un carattere di tabulazione nella parte di rientro iniziale della riga come errore (abilitato per impostazione predefinita).

• indent-with-non-tab considera una riga con caratteri di spazio anziché le schede equivalenti come errore (non abilitata per impostazione predefinita).

• tab-in-indent considera un carattere di tabulazione nella parte di rientro iniziale della riga come errore (non abilitato per impostazione predefinita).

• blank-at-eof considera righe vuote aggiunte alla fine del file come errore (abilitato per impostazione predefinita).

• trailing-space è una mano breve per coprire sia blank-at-eol e blank-at-eof.

• cr-at-eol tratta di un ritorno a capo alla fine della linea come parte della terminazione di linea, cioè con esso, trascinamento spazio non determinano se il carattere prima come un carrello-ritorno non è uno spazio bianco (non abilitato di predefinito).

• tabwidth=<n> indica quante posizioni di carattere occupa una scheda; questo è rilevante per indent-with-non-tab e quando Git corregge errori di tab-in-indent. La larghezza scheda predefinita è 8. I valori consentiti sono da 1 a 63.

---

Come si può vedere, blank-at-eof è abilitato di default. È possibile disabilitarlo aggiungendo -blank-at-eof alla configurazione core.whitespace o in alternativa utilizzando la propria configurazione core.whitespace.