In un progetto in cui alcuni file contengono ^ M come separatori newline. Diffondere questi file è apparentemente impossibile, dal momento che git-diff lo vede come l'intero file è solo una singola riga.

In che modo si differenzia dalla versione precedente?

Esiste un'opzione come "tratta ^ M come newline quando diffing"?

prompt> git-diff "HEAD^" -- MyFile.as 
diff --git a/myproject/MyFile.as b/myproject/MyFile.as
index be78321..a393ba3 100644
--- a/myproject/MyFile.cpp
+++ b/myproject/MyFile.cpp
@@ -1 +1 @@
-<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
\ No newline at end of file
+<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
\ No newline at end of file
prompt>

AGGIORNARE:

ora ho scritto uno script di Ruby che verifica le ultime 10 revisioni e converte CR in LF.

require 'fileutils'

if ARGV.size != 3
  puts "a git-path must be provided"
  puts "a filename must be provided"
  puts "a result-dir must be provided"
  puts "example:"
  puts "ruby gitcrdiff.rb project/dir1/dir2/dir3/ SomeFile.cpp tmp_somefile"
  exit(1)
end

gitpath = ARGV[0]
filename = ARGV[1]
resultdir = ARGV[2]

unless FileTest.exist?(".git")
  puts "this command must be run in the same dir as where .git resides"
  exit(1)
end

if FileTest.exist?(resultdir)
  puts "the result dir must not exist"
  exit(1)
end
FileUtils.mkdir(resultdir)

10.times do |i|
  revision = "^" * i
  cmd = "git show HEAD#{revision}:#{gitpath}#{filename} | tr '\\r' '\\n' > #{resultdir}/#{filename}_rev#{i}"
  puts cmd 
  system cmd
end

GitHub suggerisce che dovresti assicurarti di usare \ n solo come carattere di nuova riga nei repository gestiti da git. C'è un'opzione per la conversione automatica:

$ git config --global core.autocrlf true

Naturalmente, si dice che converta crlf in lf, mentre tu vuoi convertire cr in lf. Spero che funzioni ancora ...

E poi converti i tuoi file:

# Remove everything from the index
$ git rm --cached -r .

# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add

# Commit
$ git commit -m "Fix CRLF"

core.autocrlf è descritto nella pagina man .

Sviluppandomi su Windows, ho riscontrato questo problema durante l'utilizzo git tfs. L'ho risolto in questo modo:

git config --global core.whitespace cr-at-eol

Questo sostanzialmente dice a Git che un CR di fine linea non è un errore. Di conseguenza, quei fastidiosi ^Mcaratteri non appaiono più alla fine di linee in git diff, git showecc

Sembra lasciare le altre impostazioni così come sono; ad esempio, gli spazi extra alla fine di una riga vengono comunque visualizzati come errori (evidenziati in rosso) nel diff.

(Altre risposte hanno fatto allusione a questo, ma quanto sopra è esattamente come impostare l'impostazione. Per impostare un'impostazione per un solo progetto, omettere il --global.)

MODIFICA :

Dopo molti travagli di fine riga, ho avuto la migliore fortuna, lavorando su un team .NET, con queste impostazioni:

• NO impostazione core.eol
• NESSUNA impostazione core.whitespace
• NO impostazione core.autocrlf
• Quando esegui il programma di installazione di Git per Windows, otterrai queste tre opzioni:
  • Acquista in stile Windows, esegui il commit delle terminazioni di linea in stile Unix <- scegli questa
  • Acquista così com'è, impegna le terminazioni di linea in stile Unix
  • Acquista così com'è, esegui il commit così com'è

Se è necessario utilizzare l'impostazione degli spazi bianchi, probabilmente è necessario abilitarla solo per progetto se è necessario interagire con TFS. Ometti il --global:

git config core.whitespace cr-at-eol

Se è necessario rimuovere alcune impostazioni di base. *, Il modo più semplice è eseguire questo comando:

git config --global -e

Questo apre il tuo file .gitconfig globale in un editor di testo e puoi facilmente eliminare le righe che vuoi rimuovere. (Oppure puoi mettere '#' davanti a loro per commentarli.)

Prova git diff --ignore-space-at-eol, o git diff --ignore-space-change, o git diff --ignore-all-space.

Vedi anche:

core.whitespace = cr-at-eol

o equivalentemente,

[core]
    whitespace = cr-at-eol

dove whitespaceè preceduto da un carattere di tabulazione .

Perché hai questi ^Mnel tuo git diff?

Nel mio caso stavo lavorando a un progetto sviluppato in Windows e ho usato OS X. Quando ho cambiato del codice, ho visto ^Malla fine delle righe che ho aggiunto git diff. Penso che si ^Mstessero presentando perché erano terminazioni di linea diverse rispetto al resto del file. Poiché il resto del file è stato sviluppato in Windows, utilizzava le CRterminazioni di linea e in OS X utilizza le LFterminazioni di linea.

Apparentemente, lo sviluppatore di Windows non ha utilizzato l'opzione " Verifica in stile Windows, esegui il commit di terminazioni di linea in stile Unix " durante l'installazione di Git.

Quindi cosa dovremmo fare al riguardo?

Puoi fare in modo che gli utenti Windows reinstallino git e utilizzare l' opzione " Verifica stile Windows, commit terminazioni di linea in stile Unix ". Questo è ciò che preferirei, perché vedo Windows come un'eccezione nei caratteri di fine riga e Windows risolve il proprio problema in questo modo.

Se scegli questa opzione, dovresti comunque correggere i file correnti (perché stanno ancora usando le CRterminazioni di riga). L'ho fatto seguendo questi passaggi:

1. Rimuovi tutti i file dal repository, ma non dal tuo filesystem.

   git rm --cached -r .
   

2. Aggiungi un .gitattributesfile che impone a determinati file di utilizzare un LFfinale di riga. Metti questo nel file:

   *.ext text eol=crlf
   

   Sostituisci .extcon le estensioni dei file che desideri abbinare.

3. Aggiungi di nuovo tutti i file.

   git add .
   

   Questo mostrerà messaggi come questo:

   warning: CRLF will be replaced by LF in <filename>.
   The file will have its original line endings in your working directory.
   

4. È possibile rimuovere il .gitattributesfile a meno che non si disponga di utenti Windows testardi che non desiderano utilizzare l' opzione " Verifica stile Windows, commit terminazioni di linea in stile Unix ".

5. Impegnati e spingi tutto.

6. Rimuovere e verificare i file applicabili su tutti i sistemi in cui vengono utilizzati. Sui sistemi Windows, assicurati che ora utilizzino l' opzione " Verifica in stile Windows, esegui il commit di terminazioni di linea in stile Unix ". Dovresti anche farlo sul sistema in cui hai eseguito queste attività perché quando hai aggiunto i file git ha detto:

   The file will have its original line endings in your working directory.
   

   Puoi fare qualcosa del genere per rimuovere i file:

   git ls | grep ".ext$" | xargs rm -f
   

   E quindi questo per ripristinarli con le terminazioni di riga corrette:

   git ls | grep ".ext$" | xargs git checkout
   

   Ovviamente sostituendolo .extcon l'estensione desiderata.

Ora il tuo progetto usa solo LFpersonaggi per i finali di linea e i CRpersonaggi cattivi non torneranno mai più :).

L'altra opzione è quella di applicare le terminazioni di linea in stile Windows. Puoi anche usare il .gitattributesfile per questo.

Maggiori informazioni: https://help.github.com/articles/dealing-with-line-endings/#platform-all

Esiste un'opzione come "tratta ^ M come newline quando diffing"?

Ce ne sarà uno con Git 2.16 (Q1 2018), poiché la " diff" famiglia di comandi ha imparato a ignorare le differenze nel ritorno a capo alla fine della riga.

Vedi commit e9282f0 (26 ott 2017) di Junio ​​C Hamano ( gitster) .
Assistito da: Johannes Schindelin (dscho ) .
^{(Unita da Junio ​​C Hamano - gitster- in commit 10f65c2 , 27 nov 2017)}

diff: --ignore-cr-at-eol

Una nuova opzione --ignore-cr-at-eoldice al macchinario diff di trattare un ritorno a capo alla fine di una linea (completa) come se non esistesse.

Proprio come gli altri "--ignore-* " opzioni per ignorare vari tipi di differenze di spazi bianchi, questo ti aiuterà a rivedere le reali modifiche apportate senza essere distratto dalla CRLF<->LFconversione spuria effettuata dal tuo programma di editor.

TL; DR

Cambia il core.pagerin "tr -d '\r' | less -REX", non il codice sorgente

Ecco perché

Quelle fastidiose ^ M mostrate sono un artefatto della colorizzazione e del cercapersone. È causato da less -Run'opzione cercapersone git predefinita. (il pager predefinito di git è less -REX)

La prima cosa da notare è che git diff -bnon mostrerà cambiamenti nello spazio bianco (ad es. \ R \ n vs \ n)

impostare:

git clone https://github.com/CipherShed/CipherShed
cd CipherShed

Un rapido test per creare un file unix e modificare le terminazioni di riga non mostrerà modifiche con git diff -b:

echo -e 'The quick brown fox\njumped over the lazy\ndogs.' > test.txt
git add test.txt
unix2dos.exe test.txt
git diff -b test.txt

Notiamo che forzare una pipe a meno non mostra ^ M, ma abilita il colore e less -Rfa:

git diff origin/v0.7.4.0 origin/v0.7.4.1 | less
git -c color.ui=always diff origin/v0.7.4.0 origin/v0.7.4.1 | less -R

La correzione viene mostrata usando una pipe per rimuovere \ r (^ M) dall'output:

git diff origin/v0.7.4.0 origin/v0.7.4.1
git -c core.pager="tr -d '\r' | less -REX"  diff origin/v0.7.4.0 origin/v0.7.4.1

Un'alternativa poco saggia è usare less -r, perché passerà attraverso tutti i codici di controllo, non solo i codici colore.

Se vuoi semplicemente modificare direttamente il tuo file git config, questa è la voce per aggiornare / aggiungere:

[core]
        pager = tr -d '\\r' | less -REX

Ho lottato con questo problema per molto tempo. Di gran lunga la soluzione più semplice è quella di non preoccuparsi dei caratteri ^ M e usare semplicemente uno strumento di visualizzazione visiva in grado di gestirli.

Invece di digitare:

git diff <commitHash> <filename>

provare:

git difftool <commitHash> <filename>

Nel mio caso, che cosa è stato questo comando:

git config  core.whitespace cr-at-eol

Fonte: https://public-inbox.org/git/8d7e4807-9a79-e357-8265-95f22ab716e0@web.de/T/

Come notato da VonC, questo è già stato incluso in git 2.16+. Sfortunatamente, il nome dell'opzione ( --ignore-cr-at-eol) differisce da quello usato da GNU diff a cui sono abituato ( --strip-trailing-cr).

Quando mi sono trovato di fronte a questo problema, la mia soluzione era quella di invocare GNU diff invece del diff incorporato di git, perché il mio git è più vecchio di 2.16. L'ho fatto usando questa riga di comando:

GIT_EXTERNAL_DIFF='diff -u --strip-trailing-cr "$2" "$5";true;#' git diff --ext-diff

Ciò consente l'utilizzo --strip-trailing-cre qualsiasi altra opzione diff GNU.

C'è anche questo altro modo:

git difftool -y -x 'diff -u --strip-trailing-cr'

ma non utilizza le impostazioni del cercapersone configurate, motivo per cui preferisco la prima.