summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2006-10-29 07:47:56 (GMT)
committerJunio C Hamano <junkio@cox.net>2006-10-29 07:49:17 (GMT)
commitc7740a943ec896247ebc5514b6be02710caf3c53 (patch)
treeab918e6d34d35d714a180f57e946afdc81aa0a57 /Documentation
parentb89c4e93cc1939493c2bb9b6c3f60eabaf653eff (diff)
downloadgit-c7740a943ec896247ebc5514b6be02710caf3c53.zip
git-c7740a943ec896247ebc5514b6be02710caf3c53.tar.gz
git-c7740a943ec896247ebc5514b6be02710caf3c53.tar.bz2
send-pack --keep: do not explode into loose objects on the receiving end.
This adds "keep-pack" extension to send-pack vs receive pack protocol, and makes the receiver invoke "index-pack --stdin --fix-thin". With this, you can ask send-pack not to explode the result into loose objects on the receiving end. I've patched has_sha1_file() to re-check for added packs just like is done in read_sha1_file() for now, but I think the static "re-prepare" interface for packs was a mistake. Creation of a new pack inside a process that needs to read objects in them back ought to be a rare event, so we are better off making the callers (such as receive-pack that calls "index-pack --stdin --fix-thin") explicitly call re-prepare. That way we do not have to penalize ordinary users of read_sha1_file() and has_sha1_file(). We would need to fix this someday. Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions