Re: Why pack+unpack?

Linus Torvalds <torvalds@osdl.org> writes:

An alternative code path specialized for local case would not be too bad.

First, finding the list of objects to copy. You can use alternate object pool to cover the upstream repository to pull from, and the downstream repository to pull into (both local), run rev-list --objects, giving it prefix '^' for all refs in the downstream repository, and the upstream head SHA1 you are pulling. If the upstream head you are pulling is a tag, then you may need to dereference it as well.

Among those objects, ones unpacked in the upstream can be copied/linked to the downstream repository.

Handling packs involves a little bit of policy decision. The current pack/unpack way always unpacks, and to emulate it, we can cat-file in the upstream object database, pipe that to "hash-object -w" (after giving hash-object an option to read from the standard input) to write in the downstream repository unpacked. Easier alternative is to just hardlink all the packs from the upstream object database into the downstream object database, and keep packed things packed.

Well, it starts to sound somewhat bad...