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