1

Symptoms

I have a strange issue where I want to checkout a different branch <branch2>, but when I try I get the message that 

$ 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

However git ls-files lists <filename.xlsx> as a tracked file.

Workaround

If I do a git checkout -f <branch2> it works, and the <branch2> version of the excel file is present and correct (similarly if I rm <filename.xlsx> and then checkout I get the correct file.)

To move back to <branch1> I get the exact same issue (<filename.xlsx> is tracked, but for checkout appears to be untracked).

Testing/Troubleshooting

Investigating further this seems to be related to a Windows/Linux issue:

  • I work predominantly in a VirtualBox VM of Debian, so I use my git tooling and terminal there, and access via a VirtualBox shared folder.
  • Some of my code (this repository included) lives on the host system (Windows 10) as it is platform specific.
  • If I use Git for Windows this issue does not occur.
  • If I clone to a linux filesystem this issue does not occur.
  • If I clone from upstream to a different Windows folder and access from linux I get the same issue.
  • Other branches in the same repository that have the same file with different contents again do not suffer from the same issue (ie checkouts work as expected)
  • Other commits with the same version of the file have the same issue.
  • A small repo with just these two file versions does not exhibit the same behaviour, so, unfortunately, no easy way to create MCVE.

Final Thoughts

Honestly, it is something that is relatively easy to work around, and seems limited in scope so far to only these two copies of the , but it has me intrigued. If anyone with greater knowledge of git has any ideas on how to diagnose/fix the root cause of this issue I would be very grateful.

Extra debugging

Here is the results of git ls-files --debug from <branch1>

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

Here is the results of git ls-files --debug from <branch2>

Codesheet.xlsx
  ctime: 1489467487:720851100
  mtime: 1489467487:720851100
  dev: 38   ino: 5502
  uid: 0    gid: 999
  size: 12546   flags: 0
Gavin
  • 1,070
  • 18
  • 24
  • 1
    That *is* puzzling, because "untracked" literally means "not in the index". I'd suggest using `git ls-files --debug` to examine things more closely, and also check for "invisible" file name characters (white space, non-printing control characters, and the like). – torek Mar 14 '17 at 04:42
  • @torek Had a look there and the main thing that is popping out is a case change between the two branches (which I hadn't noticed earlier). This is obviously the cause. Thanks heaps. at least I can "fix" it now. – Gavin Mar 14 '17 at 05:05

1 Answers1

4

Just a guess: this could be a case of a file with a different case but the same name.
From the case-insensitive Windows OS perspective, it is tracked, but from a case-sensitive Debian OS perspective, it is not tracked.

Try:

 git config core.ignorecase true

The OP Gavin mentions in the comments using "Changing capitalization of filenames in Git", with the git mv command.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for this. I did figure out in the end that it was indeed a case issue. I should have clicked that this was a possible reason for the issue as I think I even glanced at that question when I was searching. I've solved this specific instance of the issue in a different way by using your answer on [git mv](http://stackoverflow.com/a/24979063/1468125). – Gavin Mar 14 '17 at 13:05
  • 1
    @Gavin Great. I have include `git mv` in the answer for more visibility. – VonC Mar 14 '17 at 13:06