I posted up the following to the git community mailing list the other day
When using git fetch --prune, git will remove any branches from remotes/origin/ that have inconsistent case in folder names. This issue has been verified in versions 1.7.10.2, 1.7.11.1 and 1.8.3.2. I've described the reproduction steps here as I carried them out, and listed the plaforms I used to replicate it. The issue will most likely occur on a different combination of platforms also. - On Mac, create a new repository and push a master branch to a central server - On Mac, create a branch called feature/lower_case_branch and push this to the central server (note that 'feature' is all lower case) - On Windows, clone the repository but stay on master, do not checkout the feature/lower_case_branch branch - On Windows, branch from master a branch called Feature/upper_case_branch (note the uppercase F) and push to the server - On Mac, run git fetch and see that remote/origin/Feature/upper_case_branch is updated Couple of things to note here 1) In the git fetch output it lists the branch with an upper case 'F' * [new branch] Feature/upper_case_branch -> origin/Feature/upper_case_branch 2) When I run git branch --all it is actually listed with a lower case 'f' remotes/origin/feature/upper_case_branch Now the problem happens when I run git fetch --prune, I get the following output * [new branch] Feature/upper_case_branch -> origin/Feature/upper_case_branch x [deleted] (none) -> origin/feature/upper_case_branch Note the new branch uses 'F' and the deleted branch uses 'f'. The results of this bug seem to be * Everytime I call git fetch it thinks Feature/upper_case_branch is a new branch (if I call 'git branch' multiple times I always get the [new branch] output) * Whenever I run with --prune, git will *always* remove the branch with a different folder name (from a case sensitive perspective) than the one originally created on the current machine.
I’ve yet to receive a response as to whether this is an actual bug (certainly looks like it) or expected behaviour, but it caused quite a bit of running around trying to find a solution to it (I originally thought it was a SourceTree bug). Since our branches are extremely transient, we use –prune a lot so not being able to use it would have caused quite a few issues.
Luckily it can be worked around by calling ‘git fetch –prune’ followed directly with ‘git fetch’ and depending on what tool you’re using, adding this as a custom step is usually pretty easy.
Here’s the link to the list thread if you want to follow it.
Sounds like fallout from the fact that, by default, NTFS and the OS X file system are case preserving but not case sensitive.
Git assumes a POSIX-like environment. Virtually all file systems used in POSIX environments are case sensitive.