David Turner <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
