可以指示git只写packfiles吗？

Question

I sometimes store git repositories on Flash media, which is slow to create multiple, individual files but fairly quick at writing single large files. The repositories are bare repositories, so it's basically just the .git folder.

Whenever I push to these repositories, I notice that git copies a pack file, but then unpacks it. I really don't want git to unpack objects; rather, I want it to keep the objects compressed.

Is there a way to instruct git to only write packfiles and not unpack them?

Answer 1

Reviewing the standard config options that git supports , I happened to read the following description of receive.unpackLimit :

If the number of objects received in a push is below this limit then the objects will be unpacked into loose object files. However if the number of received objects equals or exceeds this limit then the received pack will be stored as a pack, after adding any missing delta bases. Storing the pack from a push can make the push operation complete faster, especially on slow filesystems. If not set, the value of transfer.unpackLimit is used instead.

I configured one of the bare repositories on the Flash drive with transfer.unpackLimit set to 0 and a subsequent push of 7 objects did not result in unpacking.

Answer 2

I'm not an adept of git repacking, but I would try looking at git-repack .

This script is used to combine all objects that do not currently reside in a "pack", into a pack. It can also be used to re-organize existing packs into a single, more efficient pack.

A pack is a collection of objects, individually compressed, with delta compression applied, stored in a single file, with an associated index file.

Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc.

Edit 1 : maybe the -a option is what you're looking for:

-a

Instead of incrementally packing the unpacked objects, pack everything referenced into a single pack. Especially useful when packing a repository that is used for private development and there is no need to worry about people fetching via dumb protocols from it. Use with -d. This will clean up the objects that git prune leaves behind, but git fsck --full shows as dangling.

Edit 2 : As I stated in the comment, this is not a real answer, but rather a possible pointer to try with.

Answer 3

A nice solution for what you'd like to do might be bup . The idea of bup is to write git pack files directly (and independently of git) so that you can use the efficient pack file format for backups, without git's performance problems with repacking huge repositories.

An example of how you might create pack files in a remote git repository is given in the "Make a backup on a remote server" example in bup's README .

As a disclaimer, I haven't tried this myself, so maybe there's some fundamental problem with using bup for your use case, but it seems like a nice idea to me.