David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > I would be happy to add "case-clone" to the glossary -- would that be OK > with you? I do not immediately think of the better term. Somehow "case-clone" sounds strange, though X-<. >> (Mental note to the reviewer himself) This returns true iff there is >> an existing ref whose name is only different in case, and cause >> for-each-ref to return early with true. In a sane case of not >> receiving problematic refs, this will have to iterate over all the >> existing refnames. Wonder if there are better ways to optimize this >> in a repository with hundreds or thousands of refs, which is not all >> that uncommon. > > My expectation is that on average a push will involve a small number of > refs -- usually exactly one. It does not matter that _you_ push only one, because the number of existing refs at the receiving end is what determines how many times the for-each-ref loop spins, no? > Yes, but it's harder to test on case-insensitive filesystems because we > cannot have coexisting local case-clone branches. You do not have to (and you should not) do "git checkout -b" to create various local branches in the first place. For example: git send-pack ./victim HEAD^1:refs/heads/caseclone && test_must_fail git send-pack ./victim HEAD:refs/heads/CaseClone would let you push the parent of the current tip to caseclone and then attempt to push the current tip to CaseClone. If the receiving end could incorrectly fast-forwards caseclone, you found a bug ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html