linux - Sådan repareres en git-sporet fil, der behandles som uopspillet?

Indlæg af Hanne Mølgaard Plasc

Problem



Symptomer



Jeg har et mærkeligt problem, hvor jeg vil checke en anden gren <branch2>, men når jeg prøver, får jeg beskeden om at


$ git checkout <branch2>
error: The following untracked working tree files would be overwritten by checkout:
    <filename.xlsx>
Please move or remove them before you switch branches.
Aborting


Men git ls-files lister <filename.xlsx> som en sporet fil.


Løsning



Hvis jeg laver en git checkout -f <branch2>, fungerer den, og <branch2> versionen af ​​Excel-filen er til stede og korrekt (ligeledes hvis jeg rm <filename.xlsx> og derefter kassen får jeg den rigtige fil.)


For at flytte tilbage til <branch1> får jeg det samme problem (<filename.xlsx> spores, men for kassen ser ud til at være untracked).


Test/fejlfinding



Undersøgelse af dette synes at være relateret til et Windows/Linux problem:



  • Jeg arbejder overvejende i en VirtualBox VM i Debian, så jeg bruger min git-værktøj og terminal der og adgang via en shared folder fra VirtualBox.

  • Nogle af min kode (dette lager medfølger) lever på værtssystemet (Windows 10), da det er platformspecifik.

  • Hvis jeg bruger Git til Windows, forekommer dette problem ikke.

  • Hvis jeg kloner til et Linux-filsystem, forekommer dette problem ikke.

  • Hvis jeg kloner fra opstrøms til en anden Windows-mappe og adgang fra Linux, får jeg det samme problem.

  • Andre filialer i samme arkiv, der har samme fil med forskellige indhold igen ikke lider af det samme problem (dvs. checkout fungerer som forventet)

  • Andet, der forpligter sig til den samme version af filen, har det samme problem.

  • En lille repo med bare disse to filversioner udviser ikke den samme adfærd, så desværre ikke nogen nem måde at oprette MCVE på.



Endelige tanker



Ærligt, det er noget, der er relativt nemt at arbejde rundt, og synes at være begrænset i omfang hidtil til kun disse to eksemplarer af, men det har mig fascineret. Hvis nogen med større kendskab til git har nogen ideer om, hvordan man kan diagnosticere/rette årsagen til dette problem, ville jeg være meget taknemmelig.


Ekstra fejlfinding



Her er resultaterne af git ls-files --debug fra <branch1>


CodeSheet.xlsx
  ctime: 1489465633:751038200
  mtime: 1489465633:751038200
  dev: 38   ino: 5432
  uid: 0    gid: 999
  size: 14752   flags: 0


Her er resultaterne af git ls-files --debug fra <branch2>


Codesheet.xlsx
  ctime: 1489467487:720851100
  mtime: 1489467487:720851100
  dev: 38   ino: 5502
  uid: 0    gid: 999
  size: 12546   flags: 0

Bedste reference


Bare et gæt: dette kunne være tilfældet med en fil med en anden sag, men det samme navn.

Fra det tilfældige ufølsomme Windows OS-perspektiv er det sporet, men fra et case-sensitive Debian OS-perspektiv er det ikke sporet.


Prøve:


 git config core.ignorecase true


OP Gavin nævner i kommentarerne ved hjælp af 'Ændring af kapitalisering af filnavne i Git' med kommandoen git mv. [22]