On Fri, 8 Jul 2005, Petr Baudis wrote:

> It seems like the whole pull family is totally borked now, and I'm
> getting desperate. Looks like this evening will be *pull.c fixing for
> me.
> Jul 04 Daniel Barkalow  [PATCH 0/2] Support for transferring pack files in 
> git-ssh-*
> is what brings some hope to my life, though. Daniel? Any chance we could
> get the similar fixes for local-pull? (I didn't actually look at the
> patch but briefly.)

This patch is not actually for transferring objects which are in pack
files in the source, but for transferring a group of objects as a pack
file. It does, however, read the source side with git-pack-objects to
generate the content to send, so it would, I guess, fix the problem for
the case where it decides to use a pack to transfer.

The real fix is to go through the pull methods (local-pull and
ssh-pull; http-pull presumably won't be encountering pack files yet) and
make them do appropriate things with pack files.

One thing that is in the patch is a change to the comment, specifying
that fetch() could also get other objects in addition to the one
specified, if there's some reason to think this is a good idea; the fix
for local-pull is probably to link/symlink/copy the pack file if the
object is in one.

For ssh-pull, serve_object in ssh-push needs to be taught how to extract
an object from a pack file and send it.

However, there's a bug in pull.c, covering up a terrible performance
issue: it doesn't actually make sure you have all the parent of a commit
that you had when it checked (due to not having a way of caching the
result of checking this, which would require you to put the entire
repository through cache each time you pull). This would mean that, if you
have a pack that references something outside of it, you won't get
everything with my proposal above.

I should be able to spend some time on these issues over the weekend.

*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

Reply via email to