summaryrefslogtreecommitdiff
path: root/unpack-objects.c
AgeCommit message (Collapse)AuthorFilesLines
2006-02-09remove delta-against-self bitLibravatar Nicolas Pitre1-3/+2
After experimenting with code to add the ability to encode a delta against part of the deltified file, it turns out that resulting packs are _bigger_ than when this ability is not used. The raw delta output might be smaller, but it doesn't compress as well using gzip with a negative net saving on average. Said bit would in fact be more useful to allow for encoding the copying of chunks larger than 64KB providing more savings with large files. This will correspond to packs version 3. While the current code still produces packs version 2, it is made future proof so pack versions 2 and 3 are accepted. Any pack version 2 are compatible with version 3 since the redefined bit was never used before. When enough time has passed, code to use that bit to produce version 3 packs could be added. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-06unpack-objects: default to quiet if stderr is not a tty.Libravatar Junio C Hamano1-0/+2
This would help cron/at jobs that run send-pack to mirror repositories. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-19xread/xwrite: do not worry about EINTR at calling sites.Libravatar Junio C Hamano1-10/+3
We had errno==EINTR check after read(2)/write(2) sprinkled all over the places, always doing continue. Consolidate them into xread()/xwrite() wrapper routines. Credits for suggestion goes to HPA -- bugs are mine. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-28Make the rest of commands work from a subdirectory.Libravatar Junio C Hamano1-0/+2
These commands are converted to run from a subdirectory. commit-tree convert-objects merge-base merge-index mktag pack-objects pack-redundant prune-packed read-tree tar-tree unpack-file unpack-objects update-server-info write-tree Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-14Document the -n command-line option to git-unpack-objectsLibravatar Nikolai Weibull1-1/+1
This patch documents the -n command-line option to git-unpack-objects, as it was previously undocumented. Signed-off-by: Nikolai Weibull <nikolai@bitwi.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-12Update unpack-objects usage and documentation.Libravatar Junio C Hamano1-1/+1
It long supported -q flag to suppress progress meter without properly being documented.
2005-08-03[PATCH] Plug memory leaks in git-unpack-objectsLibravatar Sergey Vlasov1-1/+5
- Call inflateEnd to release zlib state after use. - After resolving delta, free base object data. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-10Fix up progress report for off-by-one errorLibravatar Linus Torvalds1-2/+2
We used to print the index of the object we unpacked, not how many we had unpacked. Which caused slightly confusing progress reports like 100% (2/3) done rather than the more obvious "3/3" for 100% ;)
2005-07-09git-unpack-objects: show progress report by defaultLibravatar Linus Torvalds1-3/+24
This ends up being very calming for big "git clone"s, since otherwise you just get very frustrated with a long silence, wondering whether it's working at all. Use "-q" to quiet it down. Now if we could just do the same for the initial "figure out what to pack" phase, which can also be quite slow if the other end is busy (or not packed and not in cache)...
2005-07-05Don't special-case a zero-sized compression.Libravatar Linus Torvalds1-2/+0
zlib actually writes a header for that case, and while ignoring that header will get us the right data, it will also end up messing up our stream position. So we actually want zlib to "uncompress" even an empty object.
2005-06-29Re-instate dry-run logic in git-unpack-objectsLibravatar Linus Torvalds1-1/+6
It can no longer be as verbose, since it doesn't have a good way to resolve deltas (now that it is purely streaming, it cannot seek around to read the objects a delta is based on). But it can check that the thing unpacks cleanly at least as far as pack syntax goes - all the objects uncompress cleanly, and the pack has the right final SHA1.
2005-06-29Clean up git-unpack-objects a bitLibravatar Linus Torvalds1-13/+14
I'd like to add back the "dry-run" thing, but it turns out that to do it well, I'd have to keep all the object data in memory (which is not acceptable). So I'll clean it up a bit and make it do as many checks as it can.
2005-06-28Make git pack files use little-endian size encodingLibravatar Linus Torvalds1-2/+5
This makes it match the new delta encoding, and admittedly makes the code easier to follow. This also updates the PACK file version to 2, since this (and the delta encoding change in the previous commit) are incompatible with the old format.
2005-06-28git-unpack-objects: re-write to read from stdinLibravatar Linus Torvalds1-228/+190
It gets a bit more complicated to unpack in a streaming environment, but here it is. The rewrite is actually a lot cleaner in other ways, it's just a bit more subtle.
2005-06-28[PATCH] Fix unpack-objects for header length information.Libravatar Junio C Hamano1-1/+1
Standalone unpack-objects command was not adjusted for header length encoding change when dealing with deltified entry. This fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-28Change pack file format. Hopefully for the last time.Libravatar Linus Torvalds1-24/+41
This also adds a header with a signature, version info, and the number of objects to the pack file. It also encodes the file length and type more efficiently.
2005-06-28Teach packing about "tag" objectsLibravatar Linus Torvalds1-1/+2
(And teach sha1_file and unpack-object know how to unpack them too, of course)
2005-06-26csum-file interface updates: return resulting SHA1Libravatar Linus Torvalds1-1/+2
Also, make the writing of the SHA1 as a end-header be conditional: not every user will necessarily want to write the SHA1 to the file itself, even though current users do (but we migh end up using the same helper functions for the object files themselves, that don't do this). This also makes the packed index file contain the SHA1 of the packed data file at the end (just before its own SHA1). That way you can validate the pairing of the two if you want to.
2005-06-26git-pack-objects: write the pack files with a SHA1 csumLibravatar Linus Torvalds1-5/+8
We want to be able to check their integrity later, and putting the sha1-sum of the contents at the end is a good thing. The writing routines are generic, so we could try to re-use them for the index file, instead of having the same logic duplicated. Update unpack-objects to know about the extra 20 bytes at the end of the index.
2005-06-26git-unpack-objects: start removing debug outputLibravatar Linus Torvalds1-1/+0
At least the least interesting one.
2005-06-26Fix object packing/unpacking.Libravatar Linus Torvalds1-57/+44
This actually successfully packed and unpacked a git archive down to 1.3MB (17MB unpacked). Right now unpacking is way too noisy, lots of debug messages left.
2005-06-26[PATCH] Finish initial cut of git-pack-object/git-unpack-object pair.Libravatar Junio C Hamano1-16/+172
This finishes the initial round of git-pack-object / git-unpack-object pair. They are now good enough to be used as a transport medium: - Fix delta direction in pack-objects; the original was computing delta to create the base object from the object to be squashed, which was quite unfriendly for unpacker ;-). - Add a script to test the very basics. - Implement unpacker for both regular and deltified objects. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25git-unpack-objects: start parsing the actual packed dataLibravatar Linus Torvalds1-5/+58
So far we just print out the type and size.
2005-06-25First cut at git-unpack-objectsLibravatar Linus Torvalds1-0/+105
So far it just reads the header and generates the list of objects. It also sorts them by the order they are written in the pack file, since that ends up being the same order we got them originally, and is thus "most recent first".