8 Answers
8

It's not a folder that exists, it's a branch. (Well, there may be a folder/directory involved somewhere—or maybe not, as references get "packed" and stop existing as files within directories.)

If branch b exists, no branch named b/anything can be created.

Likewise, if branch dev/b exists, dev/b/c cannot be created.

This is a git internal limitation. In this particular case, remote origin has a branch named dev/sub (regardless of whether you have it or not, the important thing is whether the remote has it). In order to create, on origin, a branch named dev/sub/master, you must first delete the branch named dev/sub on origin:

git push origin :dev/sub

(Of course, deleting this branch may delete something important over there, so be sure you know what you are doing. Generally, you might want to git fetch origin first, capturing their dev/sub as your origin/dev/sub. You can then make a local branch named dev/renamed-sub pointing to the same commit, create dev/renamed-sub on the remote, delete the remote dev/sub, and then create dev/sub/master on the remote.)

If you can log in on the remote (the system that origin is hosted on), you can go into the repository over there and simply rename the local dev/sub branch. (Based on comments below, I suspect that there's a broken auto-deploy script over there as well, which probably should be fixed to only deploy "deployable" branches, rather than everything that gets pushed. But I am just guessing here.)

I guess we're just fussing over terminology here. By "internal limitation" I mean it's something git could overcome without changing how anyone uses git. An unqualified limitation would be something much more fundamental, such as, if someone breaks SHA1: while even this could be overcome (e.g., move to SHA256), the details of 40-character SHA-1s are exposed in, e.g., most hooks, so this limitation leaks into externals.
– torekMar 26 '14 at 8:01

1

That's a weirdly irritating limitation, given you might want to have release/1.1 and release/1.2 with release/1.1/hofix/prevent-upload-bork & release/1.1/hotfix/assure-user-of-competence, etc. And the error message leads one here (thank you), rather than stating the limitation! But thank you for simple and clear explanation.
– BenjohnDec 22 '16 at 13:08

2

"This is a git internal limitation." -- OK, but why? Was some logic easier to implement this way? Or some tree-traversal? Or what?
– D. KovácsJul 19 '17 at 6:12

2

@D.Kovács: by forbidding that case, Git can simply write reference hashes into files whose name is produced by treating the reference as a path name. If Git allowed both refs/tags/foo and refs/tags/foo/2, for instance, it would not be able to do this: it would need to implement its own key-value store. I think Git is going to be forced to implement its own key-value store anyway, but I do not know if they will remove the limitation then.
– torekJul 19 '17 at 6:27

1

@ĐinhAnhHuy: I don't know of any formal documentation describing this limitation. Submodules, however, are in a completely separate name-space: submodule names and branch names should not collide in the same way that branch names and file names don't collide (i.e., they do, but you add a disambiguator: git checkout -- master means check out the file named master, rather than the branch name).
– torekJul 2 '18 at 15:39

As a windows user, none of the solutions thus far solved the problem for me. The reason I was seeing this error was because (using the OP's branch names) I was trying to create a branch dev/sub but someone else had created a branch called Dev and as we all know, windows has a case insensitive file system.

So when windows tried to pull down dev/sub it was first trying to create the folder dev, but it couldn't because Dev already existed.

The solution was to delete the Dev branch locally and remotely with git branch -d Dev && git push origin :Dev. A git pull after this ran fine.

Another lesson going forward, branch names should always be lowercase to avoid this kind of gotcha's.