Re: [PATCH] Re: git-http-pull broken in latest git

[Junio C Hamano <junkio@cox.net>]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Petr Baudis <pasky@suse.cz> 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.