File visualizzati come modificati direttamente dopo un clone di Git

Al momento sto riscontrando un problema con un repository e, sebbene il mio Git-fu sia in genere buono, non riesco a risolvere questo problema.

Quando clonare questo repository, quindi cdnel repository, git statusmostra diversi file modificati. Nota: non ho aperto il repository in nessun editor o altro.

Ho provato a seguire questa guida: http://help.github.com/dealing-with-lineendings/ , ma questo non ha aiutato affatto con il mio problema.

Ci ho provato git checkout -- .molte volte, ma sembra non fare nulla.

Sono su un Mac e non ci sono sottomoduli nel repository stesso.

Il filesystem è un filesystem "Journaled HFS +" su Mac e non fa distinzione tra maiuscole e minuscole. I file sono a una riga e circa 79 KB ciascuno (sì, hai sentito bene), quindi guardare git diffnon è particolarmente utile. Ho sentito parlare di faregit config --global core.trustctime false che potrebbe aiutare, che proverò quando torno al computer con l'archivio su di esso.

Ho cambiato i dettagli del filesystem con i fatti! E ho provato il git config --global core.trustctime falsetrucco che non ha funzionato molto bene.

Ho avuto lo stesso problema sul Mac dopo aver clonato un repository. Supporrebbe che tutti i file siano stati modificati.

Dopo l'esecuzione git config --global core.autocrlf input, stava ancora contrassegnando tutti i file come modificati. Dopo aver cercato una soluzione mi sono imbattuto .gitattributesnel file nella directory home che aveva il seguente.

* text=auto

L'ho commentato e tutti gli altri repository clonati da ora in poi funzionavano bene.

Capito. Tutti gli altri sviluppatori sono su Ubuntu (penso) e quindi hanno file system sensibili al maiuscolo / minuscolo. Io, tuttavia, non lo faccio (visto che sono su un Mac). In effetti, tutti i file avevano gemelli minuscoli quando li ho guardati usando git ls-tree HEAD <path>.

Ne prenderò uno per risolverlo.

git config core.fileMode false

risolto questo problema nel mio caso

https://git-scm.com/docs/git-config

TL; DR;

core.fileMode

Se false, le differenze di bit eseguibili tra l'indice e l'albero di lavoro vengono ignorate; utile su filesystem rotti come FAT. Vedi git-update-index (1).

Il valore predefinito è true, tranne git-clone (1) o git-init (1) esaminerà e imposterà core.fileMode su false se appropriato quando viene creato il repository.

Presumo che tu stia usando Windows. La pagina GitHub a cui ti sei collegato ha i dettagli all'indietro. Il problema è che le terminazioni di riga CR + LF sono già state impegnate nel repository e poiché core.autocrlf è impostato su true o input , Git vuole convertire le terminazioni di riga in LF, quindigit status mostra che ogni file viene modificato.

Se si tratta di un repository a cui si desidera solo accedere, ma non si ha alcun coinvolgimento, è possibile eseguire il comando seguente per nascondere semplicemente il problema senza risolverlo effettivamente.

git config core.autocrlf false

Se si tratta di un repository a cui sarai attivamente coinvolto e a cui puoi impegnare le modifiche. Potresti voler risolvere il problema eseguendo un commit che modifica tutte le terminazioni di riga nel repository per utilizzare LF anziché CR + LF e quindi adottare misure per impedire che si verifichi nuovamente in futuro.

Quanto segue è preso direttamente dalla pagina man di gitattributes e dovrebbe essere preformato da una directory di lavoro pulita.

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force Git to
git reset         # re-scan the working directory.
git status        # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

Se vengono visualizzati dei file che non devono essere normalizzati git status, disattiva il loro attributo di testo prima di eseguirlo git add -u.

manual.pdf      -text

Al contrario, i file di testo che Git non rileva possono abilitare la normalizzazione manualmente.

weirdchars.txt  text

Si prega di eseguire i seguenti comandi. Questo potrebbe risolvere il problema.

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

# Write both the index and working directory from git's database.
git reset --hard

In Visual Studio, se si utilizza Git, è possibile generare automaticamente i file .gitignore e .gitattributes. Il file .getattributes generato automaticamente ha la seguente riga:

* text=auto

Questa riga si trova nella parte superiore del file. Dovevamo solo commentare la linea aggiungendo un # all'inizio. Dopo averlo fatto, le cose hanno funzionato come previsto.

Il problema potrebbe anche derivare da autorizzazioni di file diverse , come nel mio caso:

Nuovo repository clonato (Windows, Cygwin):

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Archivio remoto nudo (Linux):

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Volevo aggiungere una risposta più diretta su "Perché" questo accade, perché esiste già una buona risposta su come risolverlo.

Quindi, .gitattributesha * text=autoun'impostazione, che causa questo problema.

Nel mio caso, i file sul ramo master di GitHub avevano \r\nterminazioni. Ho composto le impostazioni sul repository per effettuare il check-in con \nfinali. Non so cosa Git controlla però. Dovrebbe verificare con finali nativi sul mio box Linux ( \n), ma immagino che abbia verificato il file con \r\nfinali. Git si lamenta perché vede i \r\nfinali estratti nel repository e mi avverte che controllerà le \nimpostazioni. Quindi i file devono "essere modificati".

Questa è la mia comprensione per ora.

Ho avuto lo stesso problema. Anche con un Mac. Guardando il repository su una macchina Linux ho notato che avevo due file:

geoip.dat e GeoIP.dat

Ho rimosso quello deprecato sulla macchina Linux e clonato nuovamente il repository sul Mac. Non sono stato in grado di estrarre, eseguire il commit, archiviare o estrarre dalla mia copia del repository in presenza di duplicati.

Lo stesso problema per me. Ho potuto vedere diverse immagini con lo stesso nome, come "textField.png" e "textfield.png" nel repository Git remoto, ma non sul mio repository locale. Sono stato in grado di vedere solo "textField.png" che non è stato utilizzato nel codice del progetto.

Si scopre che la maggior parte dei miei colleghi sono su Ubuntu usando il filesystem ext4 mentre io sono su un Mac con APFS.

Grazie alla risposta di Sam Elliott , la soluzione era abbastanza semplice. Innanzitutto ho chiesto a un collega su Ubuntu di eliminare le versioni di file ridondanti con le maiuscole, quindi eseguire il commit e il push sul telecomando.

Quindi ho eseguito il seguente:

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

# Write both the index and working directory from git's database.
git reset --hard

Alla fine, abbiamo deciso che ogni sviluppatore dovrebbe cambiare la sua configurazione Git per evitare che ciò accada mai più:

# Local Git configuration
git config core.ignorecase = true

o

# Global Git configuration
git config --global core.ignorecase = true

Ho anche avuto lo stesso problema. Nel mio caso ho clonato il repository e alcuni file mancavano immediatamente.

Ciò è stato causato dal percorso del file e dal nome file troppo lungo per Windows. Per risolverlo, clonare il repository il più vicino possibile alla radice dell'unità disco fisso per ridurre la lunghezza del percorso del file. Ad esempio, clonalo C:\A\GitRepoinvece di C:\Users Documents\yyy\Desktop\GitRepo.

Modifica il file chiamato .git/config:

sudo gedit .git/config

O:

sudo vim .git/config

Contenuti

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
    remote = origin
    merge = refs/heads/master

[branch "productapproval"]
    remote = origin
    merge = refs/heads/productapproval

Cambia filemode=truein filemode = false.

Per le nuove versioni di macOS ciò può essere causato da una funzione di sicurezza del sistema operativo.

Nel repository su cui stavo lavorando, c'era un file binario che aveva * .app come tipo di file.

Erano solo alcuni dati serializzati, ma macOS tratta tutti i file * .app come un'applicazione e poiché questo file non è stato scaricato dall'utente, il sistema lo ha ritenuto non sicuro e ha aggiunto l' com.apple.quarantineattributo del file che assicura che il file non possa essere eseguito.

Ma l'impostazione di questo attributo sul file stava anche cambiando il file e quindi appariva nel set di modifiche Git senza alcun modo per ripristinarlo.

Puoi verificare se hai lo stesso problema eseguendo $ xattr file.app.

La soluzione è piuttosto semplice, purché non sia necessario lavorare con il file. Aggiungi *.app binaryal tuo .gitattributes.

Ho copiato il mio repository locale in un'altra cartella e un gruppo di file modificati è apparso. La mia soluzione era: ho nascosto i file modificati ed eliminato lo stash . Il repository è diventato pulito.

Ho scoperto che Git trattava i miei file (.psd in questo caso) come testo. L'impostazione su un tipo binario in .gitattributes lo ha risolto.

*.psd binary

Stavo provando a fare un rebase interattivo, ma affermava che c'erano alcuni file modificati, quindi non mi avrebbe permesso di farlo adesso. Ho provato di tutto per tornare in un repository pulito, ma niente ha funzionato. Nessuna delle altre risposte ha aiutato. Ma alla fine ha funzionato ...

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

Boom! Repository pulito. Problema risolto. Poi ho dovuto abbandonare l'ultimo commit quando ho fatto il mio rebase -ie alla fine tutto è tornato pulito. Bizzarro!

Nel caso in cui aiuti qualcun altro, potrebbe esserci un'altra causa per questo problema: diverse versioni di Git. Stavo usando la versione installata di default di Git su una casella Ubuntu 18.04 (Bionic Beaver) e tutto funzionava bene, ma quando provavo a clonare il repository usando Git su Ubuntu 16.04, alcuni file venivano mostrati come modificati.

Nessuna delle altre risposte qui ha risolto il mio problema, ma l'aggiornamento delle versioni di Git per adattarsi su entrambi i sistemi ha risolto il problema.