Il titolo dice tutto.
Dopo git reset --hard
, git status
mi dà i file nella sezione Changes not staged for commit:
section.
Ho anche provato git reset .
, git checkout -- .
e git checkout-index -f -a
, inutilmente.
Quindi, come posso liberarmi di quei cambiamenti non previsti?
Questo sembra colpire solo i file di progetto di Visual Studio. Strano. Vedi questa pasta: http://pastebin.com/eFZwPn9Z . Ciò che è speciale con quei file, è che in .gitattributes ho:
*.sln eol=crlf *.vcproj eol=crlf *.vcxproj* eol=crlf
Inoltre, autocrlf
è impostato su false nel mio globale .gitconfig
. Potrebbe essere in qualche modo rilevante?
Ho avuto lo stesso problema ed era correlato al file .gitattributes
. Tuttavia il tipo di file che ha causato il problema non è stato specificato in .gitattributes
.
Sono stato in grado di risolvere il problema semplicemente correndo
git rm .gitattributes git add -A git reset --hard
Git non resetterà i file che non si trovano nel repository. Così puoi:
$ git add . $ git reset --hard
Questo metterà in scena tutte le modifiche, il che farà sì che Git sia a conoscenza di quei file e quindi li ripristini.
Se questo non funziona, puoi provare a mettere da parte e cancellare le tue modifiche:
$ git stash $ git stash drop
Ho risolto questo problema utilizzando le seguenti sequenze
1) Rimuovi tutti i file dall’indice di Git.
git rm --cached -r .
2) Riscrivi l’indice Git per raccogliere tutte le nuove terminazioni di linea.
git reset --hard
La soluzione faceva parte dei passaggi descritti su git site https://help.github.com/articles/dealing-with-line-endings/
Ho avuto lo stesso problema e stash, hard reset, pulito o anche tutti loro stavano ancora lasciando i cambiamenti. Quello che si è rivelato essere il problema era la modalità file x che non era stata impostata correttamente da git. Questo è un “problema noto” con git for windows. Le modifiche locali mostrano in gitk e git status come vecchia modalità 100755 nuova modalità 100644, senza alcuna effettiva differenza di file.
La soluzione è ignorare la modalità file:
git config core.filemode false
Maggiori informazioni qui
Ok, ho risolto il problema.
Sembrava che il file .gitattributes
contenesse:
*.sln eol=crlf *.vcproj eol=crlf *.vcxproj* eol=crlf
ha reso i file di progetto non pubblicati. Non so perché sia così, e spero davvero che qualcuno a conoscenza delle vie del git ci dia una bella spiegazione.
La mia soluzione era rimuovere questi file e aggiungere autocrlf = false
in [core]
in .git/config
.
Questo non equivale esattamente alla configurazione precedente, poiché richiede ad ogni dev di avere autocrlf = false
. Mi piacerebbe trovare una soluzione migliore.
MODIFICARE:
Ho commentato le linee incriminanti, le ho decomposte e ha funzionato. Che cosa … non nemmeno …!
Una situazione in cui ciò può accadere è quando il file in questione è stato controllato nel repository senza la configurazione corretta per le terminazioni di riga (1) risultante in un file nel repository con terminazioni di riga non corrette o finali di linee miste. Per confermare, verifica che git diff
mostri solo i cambiamenti nelle terminazioni di riga (questi potrebbero non essere visibili di default, prova git diff | cat -v
per vedere i ritorni a capo come caratteri letterali ^M
).
Successivamente, qualcuno probabilmente ha aggiunto un .gitattributes
o modificato l’impostazione core.autocrlf
per normalizzare le terminazioni di riga (2). Basato su .gitattributes
o sulla configurazione globale, Git ha applicato le modifiche locali alla tua copia di lavoro che applica la normalizzazione di fine riga richiesta. Sfortunatamente, per qualche motivo git reset --hard
non annulla queste modifiche alla normalizzazione della linea.
Soluzioni alternative in cui vengono ripristinate le terminazioni di linea locali non risolveranno il problema. Ogni volta che il file viene “visto” da git, tenterà di riapplicare la normalizzazione, dando luogo allo stesso problema.
L’opzione migliore è lasciare che git applichi la normalizzazione che vuole normalizzando tutte le terminazioni di riga nel repository per far corrispondere i .gitattributes
e .gitattributes
tali modifiche – vedere Provare a correggere i line-endings con git filter-branch, ma non avendo fortuna .
Se vuoi veramente provare a ripristinare manualmente le modifiche al file, la soluzione più semplice sembra essere quella di cancellare i file modificati e quindi di dire a git di ripristinarli, anche se noto che questa soluzione non sembra funzionare in modo coerente al 100% di il tempo ( ATTENZIONE: NON eseguire questo se i file modificati hanno modifiche diverse da quelle di linea !!):
git status --porcelain | grep "^ M" | cut -c4- | xargs rm git checkout -- .
Si noti che, a meno che non si normalizzino le terminazioni di riga nel repository a un certo punto, si continuerà a correre questo problema.
La seconda causa ansible è la mancanza di distinzione tra maiuscole e minuscole in Windows o Mac OS / X. Ad esempio, supponiamo che nel repository esista un percorso simile al seguente:
/foo/bar
Ora qualcuno su Linux impegna i file in /foo/Bar
(probabilmente a causa di uno strumento di compilazione o qualcosa che ha creato quella directory) e spinge. Su Linux, questo è in realtà ora due directory separate:
/foo/bar/fileA /foo/Bar/fileA
Il controllo di questo repo su Windows o Mac può comportare la modifica del fileA
che non può essere ripristinato, perché su ogni reset, git su Windows controlla /foo/bar/fileA
, e quindi perché Windows non fa distinzione tra maiuscole e minuscole, sovrascrive il contenuto di fileA
con /foo/Bar/fileA
, risultando in “modifica”.
Un altro caso può essere un singolo file (s) esistente nel repository, che si sovrappone al momento del check-out su un filesystem senza distinzione tra maiuscole e minuscole. Per esempio:
/foo/bar/fileA /foo/bar/filea
Potrebbero esserci altre situazioni simili che potrebbero causare tali problemi.
git su file system senza distinzione tra maiuscole e minuscole dovrebbe davvero rilevare questa situazione e mostrare un utile messaggio di avvertimento, ma al momento non lo fa (questo potrebbe cambiare in futuro – vedi questa discussione e le relative patch proposte sulla mailing list git.git).
La soluzione è di allineare il caso dei file nell’indice git e il caso sul filesystem di Windows. Questo può essere fatto su Linux che mostrerà il vero stato delle cose, OPPURE su Windows con l’utilissima utility open source Git-Unite . Git-Unite applicherà le necessarie modifiche del caso all’indice git, che può quindi essere impegnato nel repository.
(1) Questo era più probabile per qualcuno che utilizzava Windows, senza alcuna definizione .gitattributes
per il file in questione, e usando l’impostazione globale predefinita per core.autocrlf
che è false
(si veda (2)).
(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
Un’altra causa potrebbe essere il file system senza distinzione tra maiuscole e minuscole . Se sul repository sono presenti più cartelle sullo stesso livello, i cui nomi differiscono solo in base al caso, ne verrai colpito. Sfoglia il repository sorgente usando la sua interfaccia web (ad esempio GitHub o VSTS) per essere sicuro.
Per maggiori informazioni: https://stackoverflow.com/a/2016426/67824
Esegui comando pulito :
# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`) git clean -fd
Controlla il tuo .gitattributes
.
Nel mio caso ho *.js text eol=lf
in esso e l’opzione git core.autocrlf
era true
.
Mi porta alla situazione quando git autoconverts i miei file line endings e mi impedisce di risolverlo e anche git reset --hard HEAD
non ha fatto nulla.
Lo aggiusto con commenti *.js text eol=lf
nel mio .gitattributes
e non commentato dopo di esso.
Sembra che dia solo magia.
Puoi stash
da parte le tue modifiche, quindi rilasciare la scorta:
git stash git stash drop
Nessuno di questi metodi ha funzionato per me, l’unica soluzione era quella di nuotare l’intero repo e ri-clonarlo. Ciò include la memorizzazione, il reset, l’aggiunta poi il reset, le impostazioni clrf, la distinzione tra maiuscole e minuscole ecc .. Sigh ..
Ho avuto lo stesso problema. Ho fatto git reset --hard HEAD
ma ogni volta che ho fatto lo git status
vedevo alcuni file come modificati.
La mia soluzione era relativamente semplice. Ho appena chiuso il mio IDE (qui era Xcode) e ho chiuso la riga di comando (qui era il terminale sul mio Mac OS) e ho provato di nuovo e ha funzionato.
Eppure non sono mai riuscito a trovare ciò che ha originato il problema.
Ho .gitattributes
un problema simile che coinvolgeva anche .gitattributes
, ma nel mio caso era coinvolto LFS di GitHub. Sebbene questo non sia esattamente lo scenario dell’OP, penso che offra un’opportunità per illustrare cosa fa il file .gitattributes
e perché può portare a modifiche non previste sotto forma di differenze “fantasma”.
Nel mio caso, un file era già nel mio repository, come dall’inizio del tempo. In un recente commit, ho aggiunto una nuova regola di git-lfs track
utilizzando un pattern che era in retrospettiva un po ‘troppo ampio e finendo per abbinare questo antico file. So che non volevo cambiare questo file; So che non ho cambiato il file, ma ora era nelle mie modifiche non previste e nessuna quantità di checkout o hard reset su quel file stava per risolverlo. Perché?
L’estensione GitHub LFS funziona principalmente sfruttando gli hook che git
fornisce l’accesso tramite il file .gitattributes
. Generalmente, le voci in .gitattributes
specificano come devono essere elaborati i file corrispondenti. Nel caso del PO, si trattava di normalizzare le terminazioni di linea; nel mio caso, era se consentire a LFS di gestire l’archiviazione dei file. In entrambi i casi, il file effettivamente visualizzato da git
durante il calcolo di un git diff
non corrisponde al file che viene visualizzato quando si ispeziona il file. Quindi, se si modifica il modo in cui un file viene elaborato tramite il modello .gitattributes
corrispondente, esso verrà visualizzato come modifiche non modificate nel rapporto di stato, anche se non vi è alcun cambiamento nel file.
Detto questo, la mia “risposta” alla domanda è che se il cambiamento nel file .gitattributes
è qualcosa che si voleva fare, dovresti semplicemente aggiungere le modifiche e andare avanti. In caso contrario, modifica i documenti .gitattributes
per rappresentare meglio ciò che vuoi fare.
Specifiche GitHub LFS – Ottima descrizione di come si smudge
funzione clean
e smudge
chiamate per sostituire il file negli oggetti git
con un semplice file di testo con un hash.
gitattributes Documentation – Tutti i dettagli su ciò che è disponibile per personalizzare il modo in cui git
elabora i tuoi documenti.
Credo che ci sia un problema con git per Windows, dove git scrive a caso le terminazioni di linea sbagliate al checkout e l’unica soluzione è quella di controllare qualche altro ramo e forzare git ad ignorare le modifiche. Quindi controlla il ramo su cui vuoi effettivamente lavorare.
git checkout master -f git checkout
Tieni presente che questo annullerà tutte le modifiche che potresti aver fatto intenzionalmente, quindi fallo solo se hai questo problema subito dopo il checkout.
Edit: Potrei aver avuto davvero fortuna la prima volta. Si scopre che sono stato morso di nuovo dopo aver cambiato ramo. Si è scoperto che i file git stavano riportando come modificati dopo il cambio delle filiali. (Apparentemente perché git non applicava in modo coerente la riga CRLF che terminava correttamente con i file.)
Ho aggiornato all’ultima versione di Windows e spero che il problema non ci sia più.
Problema simile, anche se sono sicuro solo in superficie. Ad ogni modo, può aiutare qualcuno: cosa ho fatto (FWIW, in SourceTree): ho nascosto il file senza commit, poi ho fatto un reset hardware.
Come hanno sottolineato altre risposte, il problema è dovuto alla correzione automatica della line-end. Ho riscontrato questo problema con i file * .svg. Ho usato il file SVG per le icone nel mio progetto.
Per risolvere questo problema, faccio sapere a git che i file svg dovrebbero essere trattati come binari anziché come testo aggiungendo la riga sottostante a .gitattributes
* .svg binario