3

I am not sure how to reproduce this, or how it possibly occured, but I managed to get into a situation where git/bitbucket stored 2 branches with duplicate names.

  1. If i looked on bitbucket, under branches, i would see multiple branches with the same name.
  2. In git branch --remote i could only see 1 name.
  3. If i ran git fetch it would always inform me of a new branch.
  4. The 'duplicate' branches had different content, when i ran git fetch it would "toggle" the branches, meaning that each i ran it and did a log on the same origin/branch it would show different info.

I fixed this by deleting the branch from bitbucket, leaving only one of them (the good one). I am interested in how this could possibly have happened? Is it from git, or bitbucket?

Fantastic Mr Fox
  • 32,495
  • 27
  • 95
  • 175
  • branches are case sensitive, and can be namespaced, so `branch` is different than `Branch` and `feature/branch` is different than `ticket/branch`. This can go very weird on windows, because the windows file system is not case sensitive. – LightBender Nov 27 '18 at 13:35
  • @LightBender The branches were exactly the same, furthermore when i do `git branch --remote` it would show only one branch. Further, furthermore this doesn't explain the super freaky behaviour of toggling the branch contents when you do a `fetch`. – Fantastic Mr Fox Nov 27 '18 at 13:53
  • Can you post the list of branches? – LightBender Nov 27 '18 at 13:56
  • The branch has been deleted now, but i don't think the other branches will help, the branch name was (and is since there were 2) `feature/Compat_fixes`. Again the command `git branch --remote | sort` showed only 1 branch with this name, but bitbucket showed 2 ... – Fantastic Mr Fox Nov 27 '18 at 14:02
  • 1
    That really sounds like a problem with case sensitivity. BitBucket running on Linux will see two branches with different capitalization as two branches, your local system running on Windows would see them as only one. That explains the fetch behavior as well. Because references are stored as files in the `.git` directory, every time you fetch it would try to grab the ref you don't have, and overwrite the one you do by changing the case because it can't have two files with the same name. – LightBender Nov 27 '18 at 14:10
  • @LightBender Cool, it must have been different, you nailed it. I tested it here: https://github.com/benjamind2330/GitFeatureTest. Add the answer and i will accept it, or maybe you can find a duplicate. – Fantastic Mr Fox Nov 27 '18 at 14:34

1 Answers1

3

You're dealing with a case sensitivity issue. Atlassian Bitbucket (and especially Atlassian Bitbucket Cloud) usually runs on Linux, which has a case-sensitive file system, but you're checking it out to Windows, which is case-insensitive (at least for what we're concerned about on the file-system level).

Because Git stores references (refs) in the file system, branches follow the same rules (branches are a type of ref).

On Bitbucket, you can have two branches, feature/Compat_Fixes and feature/Compat_fixes (mind the case difference of "F" in "Fixes") . When you check this out to a Windows machine, git will first fetch one, then overwrite it with the other later (f=F).

Every time you run a fetch, Git exchanges a list of your references (refs) to compare to the remote's. Bitbucket will see you're missing one, and send it to you. Your local git will then happily overwrite the ref you have with the new one. On the next fetch, the whole process happens with the other branch.

Renaming one of the branches, deleting one, or merging them together on Bitbucket will solve the issue.

Incidentally, this can happen to files in your working directory as well.

Apart from Windows or a Mac OS(X) system that has a case insensitiv file syetem, the same applies to file-systems that can't deal with all the binary vs. character encoding of Git versus the file-system itself (see the subsection of the "git-branch" manpage close to the end labeled Discussion).

LightBender
  • 4,046
  • 1
  • 15
  • 31