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
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.
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
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