git status modifiche, git checkout — <file> non rimuoverli

StackOverflow https://stackoverflow.com/questions/2016404

Domanda

Vorrei togliere tutte le modifiche per la mia copia di lavoro.
In esecuzione git status mostra i file modificati.
Nulla mi sembra rimuovere tali modifiche.
E. g.:

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")
È stato utile?

Soluzione

Ci sono molteplici problemi possono causare questo comportamento:

Linea fine normalizzazione

Ho avuto questo tipo di problemi. Si scende a git automaticamente convertire crlf LF. Questo è in genere causato da fine riga misti in un unico file. Il file viene normalizzato nell'indice, ma quando git poi denormalizes nuovamente per diff contro il file nella struttura di lavoro, il risultato è diverso.

Ma se si vuole risolvere questo problema, è necessario disattivare core.autocrlf , modificare tutti i fine riga di lf, e quindi attivare di nuovo. Oppure si può disattivare del tutto facendo: 

git config --global core.autocrlf false

Al posto di core.autocrlf , si può anche considerare l'utilizzo di .gitattribute file . In questo modo, è possibile assicurarsi che tutti usando il repo utilizza le stesse regole di normalizzazione, impedendo fine riga misti entrare nel repository.

Guarda anche l'impostazione core.safecrlf per avvertire se si vuole git per avvisare l'utente quando una normalizzazione non reversibile verrebbe eseguita.

Il git pagine di manuale dire questo:

  

conversione CRLF porta una piccola possibilità   Dati di corrompere. autocrlf = vera volontà   convertire CRLF a LF durante commit e   LF per CRLF durante il pagamento. Un file   che contiene una miscela di LF e CRLF   prima che il commit non può essere ricreato   by git. Per i file di testo questo è il   cosa giusta da fare: corregge la linea   terminazioni tale che abbiamo solo la linea LF   terminazioni nel repository. Ma per   file binari che sono accidentalmente   classificate come testo la conversione può   dati corrotti.

file system case-insensitive

Il file system case-insensitive, quando lo stesso nome con involucro diverso è nel repository git cerca di verifica sia, ma solo uno finisce sul file system. Quando git tenta di confrontare il secondo, sarebbe confrontarlo con il file errato.

La soluzione alternativamente il passaggio a un caso inesistente system insensibile, ma in molti casi non è possibile o rinomina e commettendo uno dei file su un altro file system.

Altri suggerimenti

ho avuto questo problema su Windows, ma non era disposto a esaminare le ramificazioni di utilizzare config --global core.autocrlf false anche io non ero preparato ad abbandonare altre sedi private e goodies nella mia scorta e iniziare con un clone fresca. Ho solo bisogno di fare qualcosa. Ora.

Questo ha funzionato per me, l'idea che si lascia git riscrivere completamente la vostra directory di lavoro: 

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

(Si noti che in esecuzione solo git reset --hard non era abbastanza buono e non era un rm pianura sui file prima della reset come sono suggerito nei commenti alla domanda originale)

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

  1. Sostituire il contenuto di .gitattributes con una sola linea: * binary. Questo dice git per il trattamento di tutti i file da un file binario che non può fare nulla con.
  2. Verificare che il messaggio per i file incriminato è andato; se non è possibile git checkout -- <files> per ripristinarli alla versione repository
  3. git checkout -- .gitattributes per ripristinare il file .gitattributes al suo stato iniziale
  4. Verificare che i file non sono ancora contrassegnati come modificata.

Per le persone che hanno questo problema in futuro: avere cambiamenti FileMode possono anche avere gli stessi sintomi. git config core.filemode false lo risolverà.

Questo è stato alla guida mi fa impazzire, soprattutto che ho couldn risolvere questo problema senza che nessuna delle soluzioni trovate on-line. Ecco come ho risolto. Non può prendere i crediti qui dal momento che questo è il lavoro di un collega:)

Fonte del problema: La mia installazione iniziale di git era senza conversione riga automatico su Windows. Ciò ha causato la mia prima impegnarsi a GLFW di essere senza la corretta linea di finale.

  

Nota: Questa è solo una soluzione locale. Il ragazzo successiva clonazione repo   sarà ancora essere bloccato con questo problema. Una soluzione permanente può essere   trovato qui:    https://help.github.com/ articoli / che trattano-con-line-terminazioni / # ri-normalizzante-a-repository .

Configurazione: Xubuntu 12.04 repo Git con il progetto glfw

Problema: impossibile ripristinare i file glfw. Essi mostrano sempre come modificato, 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 riusciva a liberarsi è in file non monitorate). git checkout - non ha funzionato, non ha fatto nessuno dei suggerimenti in questa pagina. L'unica cosa che ha funzionato per me è stato quello di fare: 

git stash save --keep-index

E poi per cancellare la scorta: 

git stash drop

Ha ottenuto lo stesso problema due volte! Entrambe le volte in cui riporre alcuni cambiamenti che ho fatto e poi ha cercato di farli scoppiare di nuovo. Potrebbe'nt apparire i cambiamenti da quando ho un sacco di file vengono modificate - ma non sono! Essi sono esattamente gli stessi.

Io ora credo di aver provato tutte le soluzioni di cui sopra senza successo. Dopo aver provato la 

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

Ora ottenuto quasi tutti i file nel mio repository modificato.

Quando diffing il file, si dice ho cancellato tutte le linee e quindi aggiungere di nuovo.

Tipo di inquietante. Passo ora a evitare di stashing in futuro ..

L'unica soluzione è quella di clonare un nuovo repository e ricominciare da capo. (Fatto l'ultima volta)

Sono riuscito a risolvere questo problema temporanea cancellazione del file .gitattributes di mio repo (che definiva * text=auto e *.c text) solo.

Mi sono imbattuto git status dopo l'eliminazione e le modifiche non c'erano più. Non tornarono anche dopo .gitattributes è stato messo a posto.

Prova a fare un

  

git checkout -f

Questo dovrebbe cancellare tutti i cambiamenti nel lavoro corrente repo locale

Avere fine riga coerenti è una buona cosa. Per esempio non si innescherà fonde inutili, seppur banale. Ho visto Visual Studio creare i file con terminazioni di linea misti.

Anche alcuni programmi come bash (su Linux) non richiedono che i file .sh sono LF terminato.

Per assicurarsi che questo accade è possibile utilizzare gitattributes. Funziona a livello di repository non importa quale sia il valore di autcrlf è.

Per esempio si può avere .gitattributes come questo:     * Testo = auto

Si può anche essere più specifici per ogni tipo di file / estensione se lo facesse la materia nel tuo caso.

Poi autocrlf può convertire fine riga per i programmi Windows a livello locale.

Su un C # mista / C ++ / Java / Rubino / R, progetto Windows / Linux questo sta lavorando bene. Nessun problema finora.

Ho anche avuto stessi sintomi, ma è stato causato da cosa diversa.

Non ero in grado di: 

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

anche su git rm --cached app.js si firma come cancellati e in file non monitorate ho potuto vedere app.js. Ma quando ho provato rm -rf app.js e peform nuovo git status mi mostra ancora il file in 'non tracciata'.

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

Come la Grunt è stato acceso, e perché app.js è stato generato dalla coppia di altri file js abbiamo scoperto che dopo ogni operazione con i file js (anche questo app.js) grugnito ricreare di nuovo app.js.

Questo problema può verificarsi anche quando un collaboratore di repo lavora su una macchina Linux o Windows con Cygwin e permessi dei file vengono modificati. Git sa solo di 755 e 644.

Esempio di questo problema e come controllare per esso: 

git diff styleguide/filename

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

Per evitare questo, è necessario assicurarsi di configurazione git correttamente utilizzando 

git config --global core.filemode false

Ci sono un sacco di soluzioni e, forse, dovrebbe avere provato alcuni di questi prima che mi è venuta con la mia.Comunque qui è uno di più ...

Il nostro problema è che abbiamo avuto nessun controllo per endlines e il repository erano un mix di DOS / Unix.Il che è ancora peggio è che era in realtà un open source repo in questa posizione, e che abbiamo avuto a forcella.La decisione è stata presa, da parte di coloro primario di proprietà dell'OS repository di cambiare tutte le endlines per Unix e il commit è stato fatto, che comprendeva una .gitattributes per applicare le terminazioni di linea.

Purtroppo questo sembra causare problemi molto come descritto qui, dove una volta merge del codice da prima il DOS-2-Unix è stato fatto il file sarebbe sempre contrassegnato come modificato e non può essere ripristinato.

Durante la mia ricerca per questo mi sono imbattuto in - https://help.github.com/articles/dealing-with-line-endings/ - Se devo affrontare questo problema e io prima di provare questo fuori.

Ecco cosa ho fatto:

  1. Avevo inizialmente fatto un merge prima di realizzare non ho avuto questo problema e ha dovuto abortire che - git reset --hard HEAD (Mi sono imbattuto in un conflitto di unione.Come posso annullare l'unione?)

  2. Ho aperto il file in questione in VIM e cambiato per Unix (:set ff=unix).Uno strumento come dos2unix può essere usato al posto di corso

  3. commesso

  4. unite il master (il master ha il DOS-2-Unix cambia)

    git checkout old-code-branch; git merge master

  5. Risolti i conflitti e i file sono stati DOS di nuovo, in modo da :set ff=unix quando in VIM.(Nota che ho installato https://github.com/itchyny/lightline.vim che mi ha permesso di vedere ciò che il formato del file è il VIM linea di status)

  6. commessi.Tutto risolto!

ho commesso tutti i cambiamenti ed allora ho fatto e annullare il commit. Questo ha funzionato per me

git add.

git commit -m "Random commit"

git ripristinare --hard HEAD ~ 1

Se si clona un repository e vedere immediatamente le modifiche in sospeso, quindi il repository è in uno stato incoerente. Si prega di non commentare * text=auto dal file .gitattributes. Che è stato messo lì appositamente perché il proprietario del repository vuole che tutti i file memorizzati in modo coerente con le terminazioni di rete LF.

Come affermato da HankCa, seguendo le istruzioni riportate https: // help .github.com / articoli / trattare-con-line-terminazioni / è 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 tirare richiesta) il ramo al proprietario del pronti contro termine.

Il problema che ho incontrato è che le finestre non si preoccupa capitalizzazione nome del file, ma git fa. Così git memorizzato una versione più bassa e maiuscola del file ma potrebbe checkout solo uno.

Niente altro in questa pagina ha funzionato. Questo alla fine ha funzionato per me. Mostrando nessun file non monitorate, o commesso. 

git add -A
git reset --hard

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

git checkout <file>

Dopo la chiusura di Visual Studio il comando ha funzionato e ho potuto finalmente applicare il mio lavoro dalla pila. Così controllare tutte le applicazioni che potrebbero rendere le modifiche al codice, ad esempio SourceTree, SmartGit, blocco note, Notepad ++ e altri editor.

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

git reset --hard
git pull origin
git merge

Mi sono imbattuto in questo problema paio di volte prima.Al momento sto sviluppando su Windows 10 macchina fornita dal mio datore di lavoro.Oggi, questo particolare git comportamento è stato causato da me la creazione di un nuovo ramo dal mio "sviluppare" il ramo.Per qualche motivo, dopo sono passato di nuovo per "sviluppare" il ramo, alcuni apparentemente casuale i file sono proseguite e sono state mostrando come "modificato" in "git status".

Inoltre, a quel punto non potevo acquista un altro ramo, così mi è stato bloccato sul mio "sviluppare" il ramo.

Questo è quello che ho fatto:

$ git log

Ho notato che il nuovo ramo che ho creato da "sviluppare" prima di oggi stava mostrando nel primo "commit" del messaggio a cui si fa riferimento al termine "TESTA -> sviluppo e l'origine, di sviluppo, di origine/TESTA, Il-ramo-ho-creato-prima-oggi".

Dal momento che non ho davvero bisogno, ho cancellato:

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

I file modificati sono stati ancora mostrando, così 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 list mostra nascosto modifiche, e dato che ho avuto pochi e non aveva bisogno di uno qualsiasi dei miei nascondigli, ho fatto $ git stash clear per ELIMINARE TUTTI i NASCONDIGLI.

NOTA:Non ho provato a fare quello che qualcuno ha suggerito di qui prima di me:

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

Questo può funzionare così, sarò sicuro di provare la prossima volta che mi imbatto in questo problema.

ho risolto modificando .git / config, aggiungendo: 

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

Poi sono andato a .git / refs / teste / name_branch e posizionare l'id dell'ultimo commitenter code here

ho risolto in questo modo:

  1. Copiare il contenuto del codice corretto che si desidera
  2. Eliminare il file che causa il problema (quello che non si può tornare) dal disco. ora si dovrebbe trovare entrambe le versioni dello stesso file contrassegnato come l'eliminazione.
  3. Commit la cancellazione dei file.
  4. Crea nuovo il file con lo stesso nome e si incolla il codice corretto che avete copiato nel passaggio 1
  5. commettere la creazione del nuovo file.

Questo è quello che ha funzionato per me.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top