Re: [PATCH] Re: git-http-pull broken in latest git
On Thu, 11 Aug 2005, Junio C Hamano wrote: > 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. It was actually the patches after the http-pull fixes (the ones for parallelizing pull.c) that broke things; one advantage to fixing local-pull would be that you can set up tests for it reasonably effectively, which would have caught the regression. > > 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? The idea is that you wouldn't have to identify what situation applied yourself; you could just invoke git-ssh-pull/git-ssh-push, and it would happen faster due to the compression benefits. The point is that scripts can just pick which git-*-pull to use based on the format of the remote branch address, without variation in behavior. > 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. This is a higher priority, but writing more than bugfixes is unpleasent at the moment due to my home workstation's monitor dying, so it'll probably be next week that I'll get to it. The git-ssh-* stuff is longer-term, since it works now, and isn't even all that slow with the overlapping requests. You could, actually, probably do the local-pull fix if you wanted. I seem to recall that being your code originally; you just need to have fetch() identify that an object is in a pack, copy/link/symlink the index and pack instead of the object file, and add the pack to the list of registered packs. I've mostly been failing to deal with reading an index file that is in some directory that hasn't been registered as somewhere to read from (i.e. the source repository). -Daniel *This .sig left intentionally blank* - 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
Re: [PATCH] Re: git-http-pull broken in latest git
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
Re: [PATCH] Re: git-http-pull broken in latest git
On Thu, 11 Aug 2005, Junio C Hamano wrote: > Daniel Barkalow <[EMAIL PROTECTED]> writes: > > > It should work anyway,... > > That is true. Please forget about the "recommendation" to slurp > packs and not falling back on commit walker. > > Thanks for the patch. No problem; I had been wondering what the rest of those lines were about anyway. -Daniel *This .sig left intentionally blank* - 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
Re: [PATCH] Re: git-http-pull broken in latest git
Daniel Barkalow <[EMAIL PROTECTED]> writes: > It should work anyway,... That is true. Please forget about the "recommendation" to slurp packs and not falling back on commit walker. Thanks for the patch. - 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
