On Tue, 2014-06-03 at 15:13 -0700, Junio C Hamano wrote: > 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-<. Case clones case clones roly poly case clones; case clones case clones eat them up yum. Yeah, I wish I could think of a name that did not call to mind Tatiana Maslany, but unfortunately, that is all I can think of. At least it's easy to search for. > >> (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 that loop is an inner loop; so the total cost is O(refs pushed * existing refs). An in-memory hashmap would be O(existing refs) with a higher constant factor. An on-disk hashmap would probably scale best, but a fair amount more work. > > 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 ;-) Thanks. -- 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