At present, it is possible to have two branches which are the same but for case. This works great on the case-sensitive filesystems, but not so well on case-insensitive filesystems. It is fairly typical to have case-insensitive clients (Macs, say) with a case-sensitive server (GNU/Linux).
Should you attempt to pull on a Mac when you have case-clone branches with differing contents, you'll get an error message containing something like "Ref refs/remotes/origin/lower is at [sha-of-lowercase-branch] but expected [sha-of-uppercase-branch].... (unable to update local ref)" Fortunately, nobody uses Macs for git servers, because on a Mac server, if you push a branch called capital-M Master (that differs from lowercase-m-master), nobody else can push to (lowercase-m) master until the branch is removed. Once the branch has been removed, it can no longer be recreated. I think a git client that used only packed-refs would not have any problems with case-sensitivity of branch names, but I assume that there are good reasons this hasn't yet been done. At any rate, there are plenty of older clients out there. RFC follows: 1. On a case-insensitive server, git receive-pack ought to always reject branches which are same-but-for-case of existing branches. 2. On a case-sensitive server, the same rule by default, with an option to allow the old behavior. Let me know if, should I write these patches, they would be likely to be accepted. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
