Daniel Barkalow <[EMAIL PROTECTED]> writes: > Petr Baudis <[EMAIL PROTECTED]> writes: >> Yes, but cg-clone doesn't - it naively depended on the core git tools >> actually, er.. working. ;-)
Sorry about that. I used to have a wrapper to deal with packs around http-pull before Daniel's pack enhancement, and yanking it before really checking that enhanced http-pull actually worked was my fault as well. >> This became a nightmare to me by now - on two machines I tried to pull >> to over HTTP, that failed miserably, and I got stuck until I applied >> Daniel's patch there (and cleaned up after previous git-http-pulls). I'll push one out with two patches from Daniel today in short order. Currently running the final "make test" round. > At some point, I have to revisit getting git-ssh-* to generate exactly the > required pack and transfer that, but that's an efficiency issue, not a > correctness one, and shouldn't be relevant to the problem you're having. Wouldn't enhancing ssh-push to generate packs on the fly involve reinventing send-pack and/or upload-pack? If send-pack/receive-pack pair for the push side, and/or fetch&clone-pack/upload-pack pair for the pull side does not work as well as you would want, then ssh-push/pull pair may still be a useful tool, at the same time that means send-pack and upload-pack should be fixed to address the problem you have with them. But if that is not the case, then it might be better to declare that ssh-pull/push pair has outlived its usefulness. The same thing can be said about local-pull to a lesser degree. Lesser because people, including Pasky who said so on the list recently, would like its hard-linking behaviour, and its not exploding the existing packs, which send-pack and upload-pack would not give. So I would rate local-pull higher than ssh-push/pull on the priority scale if I were doing them. - 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
