lo stato git mostra le modifiche, checkout git - <file> non le rimuove

Vorrei rimuovere tutte le modifiche alla mia copia di lavoro.
L'esecuzione git statusmostra i file modificati.
Nulla di ciò che faccio sembra rimuovere queste modifiche.
Per esempio:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

Esistono diversi problemi che possono causare questo comportamento:

Normalizzazione fine linea

Ho avuto anche questo tipo di problemi. Si tratta di git che converte automaticamente crlf in lf. Ciò è in genere causato da terminazioni di riga miste in un singolo file. Il file viene normalizzato nell'indice, ma quando git lo denormalizza di nuovo per diffondarlo sul file nell'albero di lavoro, il risultato è diverso.

Ma se vuoi risolvere questo problema, dovresti disabilitare core.autocrlf , cambiare tutte le terminazioni di linea in lf e quindi abilitarlo di nuovo. Oppure puoi disabilitarlo del tutto facendo:

git config --global core.autocrlf false

Invece di core.autocrlf , puoi anche considerare l'uso dei .gitattributefile. In questo modo, è possibile assicurarsi che tutti coloro che utilizzano il repository utilizzino le stesse regole di normalizzazione, evitando che terminazioni di riga miste entrino nel repository.

Considera anche di impostare core.safecrlf per avvisare se vuoi che git ti avverta quando verrebbe eseguita una normalizzazione non reversibile.

Le manpage git dicono questo:

La conversione CRLF presenta una leggera possibilità di corruzione dei dati. autocrlf = true convertirà CRLF in LF durante il commit e LF in CRLF durante il checkout. Un file che contiene una combinazione di LF e CRLF prima del commit non può essere ricreato da Git. Per i file di testo questa è la cosa giusta da fare: corregge i finali di linea in modo tale che nel repository siano presenti solo i finali di linea LF. Ma per i file binari che vengono accidentalmente classificati come testo la conversione può danneggiare i dati.

File system senza distinzione tra maiuscole e minuscole

Su filesystem senza distinzione tra maiuscole e minuscole, quando nel repository è presente lo stesso nome file con un involucro diverso, git tenta di effettuare il checkout di entrambi, ma solo uno finisce nel file system. Quando git prova a confrontare il secondo, lo confronta con il file sbagliato.

La soluzione sarebbe passare a un filesystem senza distinzione tra maiuscole e minuscole, ma nella maggior parte dei casi questo non è fattibile o rinominare e eseguire il commit di uno dei file su un altro filesystem.

Stavo avendo questo problema su Windows ma non ero preparato a esaminare le ramificazioni dell'uso, config --global core.autocrlf falseinoltre non ero disposto ad abbandonare altri rami privati ​​e chicche nella mia scorta e iniziare con un nuovo clone. Devo solo fare qualcosa. Adesso.

Questo ha funzionato per me, sull'idea che hai lasciato che git riscrivesse completamente la tua directory di lavoro:

git rm --cached -r .
git reset --hard

(Si noti che l'esecuzione git reset --hardnon era abbastanza buona, né era semplice rmnei file prima di resetcome sono suggeriti nei commenti alla domanda originale)

Un'altra soluzione che può funzionare per le persone, poiché nessuna delle opzioni di testo ha funzionato per me:

1. Sostituire il contenuto di .gitattributesuna sola riga: * binary. Questo dice a git di trattare ogni file come un file binario con cui non può fare nulla.
2. Controlla che il messaggio per i file offensivi sia sparito; in caso contrario, è possibile git checkout -- <files>ripristinarli alla versione del repository
3. git checkout -- .gitattributesper ripristinare il .gitattributesfile al suo stato iniziale
4. Verificare che i file non siano ancora contrassegnati come modificati.

Per le persone future che hanno questo problema: Anche le modifiche alla modalità file possono avere gli stessi sintomi. git config core.filemode falselo aggiusterò.

Questo mi sta facendo impazzire, soprattutto che non avrei potuto risolvere questo problema senza nessuna delle soluzioni trovate online. Ecco come l'ho risolto. Non posso prendere i crediti qui perché questo è il lavoro di un collega :)

Fonte del problema: la mia installazione iniziale di git era senza conversione automatica della linea su Windows. Ciò ha comportato che il mio commit iniziale con GLFW fosse senza la fine della linea corretta.

Nota: questa è solo una soluzione locale. Il prossimo ragazzo che clonerà il repository sarà ancora bloccato con questo problema. Una soluzione permanente può essere trovata qui: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Installazione: repository Git Xubuntu 12.04 con progetto glfw

Problema: impossibile ripristinare i file glfw. Mostrano sempre come modificati, indipendentemente da ciò che ho provato.

risolto:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Ho avuto un file .bat con lo stesso problema (non riuscivo a liberarlo in file non tracciati). git checkout - non ha funzionato, né i suggerimenti in questa pagina. L'unica cosa che ha funzionato per me è stata fare:

git stash save --keep-index

E quindi per eliminare lo stash:

git stash drop

Ho ricevuto lo stesso problema due volte! Entrambe le volte quando ho nascosto alcune modifiche ho fatto e poi ho provato a riaverle. Impossibile visualizzare le modifiche poiché ho molti file che vengono modificati, ma NON lo sono! Sono ESATTAMENTE gli stessi.

Ora penso di aver provato tutte le soluzioni di cui sopra senza successo. Dopo aver provato il

git rm --cached -r .
git reset --hard

Ora ho modificato quasi tutti i file nel mio repository.

Quando si differenzia il file, si dice che ho eliminato tutte le righe e poi le ho aggiunte di nuovo.

Un po 'inquietante. Ora eviterò lo stashing in futuro ..

L'unica soluzione è clonare un nuovo repository e ricominciare. (L'ho fatto l'ultima volta)

Prova a fare un

git checkout -f

Ciò dovrebbe eliminare tutte le modifiche nell'attuale repo locale funzionante

Sono stato in grado di risolvere questo problema solo cancellando temporaneamente il file .gitattributes del mio repository (che ha definito * text=autoe *.c text).

Ho corso git statusdopo l'eliminazione e le modifiche erano sparite. Non sono tornati nemmeno dopo che .gitattributes è stato rimesso a posto.

Avere terminazioni di linea coerenti è una buona cosa. Ad esempio, non attiverà fusioni non necessarie, anche se banali. Ho visto Visual Studio creare file con terminazioni di linee miste.

Inoltre, alcuni programmi come bash (su Linux) richiedono che i file .sh abbiano terminazioni LF.

Per assicurarti che ciò accada puoi usare gitattributes. Funziona a livello di repository, indipendentemente dal valore di autcrlf.

Ad esempio puoi avere .gitattributes come questo: * text = auto

Puoi anche essere più specifico per tipo / estensione di file se è importante nel tuo caso.

Quindi autocrlf può convertire localmente le terminazioni di riga per i programmi Windows.

Su un progetto misto C # / C ++ / Java / Ruby / R, Windows / Linux funziona bene. Nessun problema finora.

Ho avuto anche gli stessi sintomi ma è stato causato da cose diverse.

Non sono stato in grado di:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

anche su di git rm --cached app.jsesso segni come cancellati e in file non tracciati ho potuto vedere app.js. Ma quando ho provato rm -rf app.jse peform di git statusnuovo mi mostra ancora il file in "non tracciato".

Dopo un paio di tentativi con il collega, abbiamo scoperto che è stato causato da Grunt!

Come Gruntè stato attivato, e poiché app.js è stato generato da un paio di altri file js abbiamo scoperto che dopo ogni operazione con i file js (anche questo app.js) grunt ricreare nuovamente app.js.

Questo problema può verificarsi anche quando un contributore al repository funziona su una macchina Linux o quando vengono modificate le finestre con Cygwin e le autorizzazioni dei file. Git conosce solo 755 e 644.

Esempio di questo problema e come verificarlo:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

Per evitare ciò, dovresti assicurarti di aver configurato git correttamente usando

git config --global core.filemode false

Ci sono molte soluzioni qui e forse avrei dovuto provare alcune di queste prima di inventarne una mia. Comunque eccone un altro ...

Il nostro problema era che non avevamo alcuna applicazione per le endline e il repository aveva un mix di DOS / Unix. Peggio ancora era che si trattava in realtà di un repository open source in questa posizione e che avevamo biforcato. La decisione fu presa da coloro che avevano la proprietà primaria del repository del sistema operativo di cambiare tutte le linee di fondo in Unix e fu preso l'impegno che includeva un .gitattributesper far rispettare le terminazioni di linea.

Sfortunatamente, questo sembrava causare problemi molto simili a quelli descritti qui, in cui una volta unificata il codice precedente al DOS-2-Unix, i file sarebbero stati contrassegnati per sempre come modificati e non potevano essere ripristinati.

Durante la mia ricerca per questo mi sono imbattuto in - https://help.github.com/articles/dealing-with-line-endings/ - Se dovessi affrontare nuovamente questo problema, inizierei provandolo.

Ecco cosa ho fatto:

1. Inizialmente avevo fatto un'unione prima di rendermi conto che avevo questo problema e dovevo interrompere questo - git reset --hard HEAD( mi sono imbattuto in un conflitto di unione. Come posso annullare l'unione? )

2. Ho aperto i file in questione in VIM e modificato in Unix ( :set ff=unix). Uno strumento simile dos2unixpotrebbe essere usato invece, ovviamente

3. impegnata

4. unito masterin (il master ha le modifiche DOS-2-Unix)

   git checkout old-code-branch; git merge master

5. Risolti i conflitti e i file erano di nuovo DOS, così come :set ff=unixin VIM. (Nota che ho installato https://github.com/itchyny/lightline.vim che mi ha permesso di vedere quale sia il formato del file nella linea di stato VIM)

6. commesso. Tutti ordinati!

Il problema che ho riscontrato è che Windows non si preoccupa della capitalizzazione dei nomi dei file, ma di Git. Quindi git ha archiviato una versione inferiore e maiuscola del file, ma ha potuto solo verificarne una.

Ho eseguito il commit di tutte le modifiche, quindi ho fatto e annullato il commit. Questo ha funzionato per me

git add.

git commit -m "Commissione casuale"

git reset --hard HEAD ~ 1

Normalmente, in GIT per cancellare tutte le tue modifiche e nuovi file, i seguenti 2 comandi dovrebbero funzionare molto bene ( ATTENZIONE , questo eliminerà tutti i tuoi nuovi file + cartelle che potresti aver creato e ripristinerà tutti i tuoi file modificati allo stato attuale commit ):

$ git clean --force -d
$ git checkout -- .

Forse a volte un'opzione migliore è semplicemente fare "git stash push" con un messaggio opzionale, in questo modo:

$ git stash push -m "not sure if i will need this later"

Questo cancellerà anche tutti i tuoi file nuovi e modificati, ma li avrai tutti nascosti nel caso in cui desideri ripristinarli. Lo stash in GIT porta da un ramo all'altro, quindi puoi ripristinarli in un altro ramo, se lo desideri.

Come nota a margine, nel caso in cui tu abbia già messo in scena alcuni file appena aggiunti e vuoi sbarazzartene, questo dovrebbe fare il trucco:

$ git reset --hard

Se tutto quanto sopra non funziona per te , leggi di seguito cosa ha funzionato per me qualche tempo fa:

Ho riscontrato questo problema alcune volte prima. Attualmente sto sviluppando su una macchina Windows 10 fornita dal mio datore di lavoro. Oggi, questo particolare comportamento git è stato causato dalla mia creazione di un nuovo ramo dal mio ramo "sviluppo". Per qualche ragione, dopo essere tornato al ramo "sviluppo", alcuni file apparentemente casuali persistevano e venivano visualizzati come "modificati" in "stato git".

Inoltre, a quel punto non ho potuto effettuare il checkout di un altro ramo, quindi ero bloccato sul mio ramo "sviluppo".

Questo è quello che ho fatto:

$ git log

Ho notato che il nuovo ramo che ho creato da "sviluppo" all'inizio di oggi è stato mostrato nel primo messaggio "commit", a cui si fa riferimento alla fine "HEAD -> sviluppo, origine / sviluppo, origine / HEAD, The-branch-i-creato -precedente-oggi ".

Dal momento che non ne avevo davvero bisogno, l'ho eliminato:

$ git branch -d The-branch-i-created-earlier-today

I file modificati erano ancora visualizzati, quindi ho fatto:

$ git stash

Questo ha risolto il mio problema:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

Naturalmente $ git stash listmostrerò i cambiamenti nascosti e, dato che ne avevo pochi e non avevo bisogno di nessuno dei miei nascondigli, l'ho fatto $ git stash clearper ELIMINARE TUTTI GLI STASH.

NOTA : non ho provato a fare ciò che qualcuno ha suggerito qui prima di me:

$ git rm --cached -r .
$ git reset --hard

Anche questo potrebbe aver funzionato, lo farò sicuramente la prossima volta che avrò questo problema.

Se si clona un repository e si vedono immediatamente le modifiche in sospeso, il repository si trova in uno stato incoerente. Si prega di NON commentare * text=autodal .gitattributesfile. Ciò è stato inserito in modo specifico perché il proprietario del repository desidera che tutti i file vengano archiviati in modo coerente con le terminazioni di riga LF.

Come affermato da HankCa, seguire le istruzioni su https://help.github.com/articles/dealing-with-line-endings/ è la strada da percorrere per risolvere il problema. Pulsante facile:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

Quindi unire (o estrarre la richiesta) il ramo al proprietario del repository.

Nient'altro in questa pagina ha funzionato. Questo alla fine ha funzionato per me. Non mostra file non tracciati o sottoposti a commit.

git add -A
git reset --hard

Per me il problema era che Visual Studio era aperto durante l'esecuzione del comando

git checkout <file>

Dopo aver chiuso Visual Studio il comando ha funzionato e ho potuto finalmente applicare il mio lavoro dallo stack. Quindi controlla tutte le applicazioni che potrebbero apportare modifiche al tuo codice, ad esempio SourceTree, SmartGit, NotePad, NotePad ++ e altri editor.

Abbiamo affrontato una situazione simile nella nostra azienda. Nessuno dei metodi proposti non ci ha aiutato. Come risultato della ricerca, il problema è stato rivelato. Il fatto era che in Git c'erano due file, i cui nomi differivano solo nel registro dei simboli. I sistemi Unix li vedevano come due file diversi, ma Windows stava impazzendo. Per risolvere il problema, abbiamo eliminato uno dei file sul server. Successivamente, nei repository locali su Windows hanno aiutato i seguenti comandi (in diverse sequenze):

git reset --hard
git pull origin
git merge

L'ho risolto modificando .git / config, aggiungendo:

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

Quindi sono andato a .git / refs / heads / name_branch e ho inserito l'id dell'ultimo commitenter code here

L'ho risolto in questo modo:

1. Copia il contenuto del codice corretto che desideri
2. Elimina il file che causa il problema (quello che non puoi ripristinare) dal tuo disco. ora dovresti trovare entrambe le versioni dello stesso file contrassegnate come cancellate.
3. Commettere la cancellazione dei file.
4. Crea di nuovo il file con lo stesso nome e incolla il codice corretto che hai copiato nel passaggio 1
5. impegnare la creazione del nuovo file.

Questo è ciò che ha funzionato per me.

Una soluzione proposta qui non ha funzionato, ho scoperto che il file era in realtà un collegamento ad alcuni caratteri speciali:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png