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
