summaryrefslogtreecommitdiff
path: root/pack-objects.c
AgeCommit message (Collapse)AuthorFilesLines
2005-12-08Document the --non-empty command-line option to git-pack-objects.Libravatar Nikolai Weibull1-1/+1
This provides (minimal) documentation for the --non-empty command-line option to the pack-objects command. Signed-off-by: Nikolai Weibull <nikolai@bitwi.se> 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-21git-repack: Properly abort in corrupt repositoryLibravatar Linus Torvalds1-1/+1
In a corrupt repository, git-repack produces a pack that does not contain needed objects without complaining, and the result of this combined with -d flag can be very painful -- e.g. a lossage of one tree object can lead to lossage of blobs reachable only through that tree. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-26pack-objects: Allow use of pre-generated pack.Libravatar Junio C Hamano1-11/+73
git-pack-objects can reuse pack files stored in $GIT_DIR/pack-cache directory, when a necessary pack is found. This is hopefully useful when upload-pack (called from git-daemon) is expected to receive requests for the same set of objects many times (e.g full cloning request of any project, or updates from the set of heads previous day to the latest for a slow moving project). Currently git-pack-objects does *not* keep pack files it creates for reusing. It might be useful to add --update-cache option to it, which would allow it store pack files it created in the pack-cache directory, and prune rarely used ones from it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-14Unlocalized isspace and friendsLibravatar Linus Torvalds1-1/+0
Do our own ctype.h, just to get the sane semantics: we want locale-independence, _and_ we want the right signed behaviour. Plus we only use a very small subset of ctype.h anyway (isspace, isalpha, isdigit and isalnum). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-13Add support for "local" packingLibravatar Linus Torvalds1-3/+21
This adds the "--local" flag to git-pack-objects, which acts like "--incremental", except that instead of ignoring all packed objects, it only ignores objects that are packed and in an alternate object tree. As a result, it effectively only does a local re-pack: any remote-packed objects will stay in the alternate object directories. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-12Fix packname hash generation.Libravatar Junio C Hamano1-4/+10
This changes the generation of hash packfiles have in their names, from "hash of object names as fed to us" to "hash of object names in the resulting pack, in the order they appear in the index file". The new "git-index-pack" command is taught to output the computed hash value to its standard output. With this, we can store downloaded pack in a temporary file without knowing its final name, run git-index-pack to generate idx for it while finding out its final name, and then rename the pack and idx to their final names. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-08[PATCH] Plug memory leak in git-pack-objectsLibravatar Sergey Vlasov1-0/+4
find_deltas() should free its temporary objects before returning. [jc: Sergey, if you have [PATCH] title on the Subject line of your e-mail, please do not repeat it on the first line in your message body. Thanks.] Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-03Make the name of a pack-file depend on the objects packed there-in.Libravatar Linus Torvalds1-6/+14
This means that the .git/objects/pack directory is also rsync'able, since the filenames created there-in are either unique or refer to the same data. Otherwise you might not be able to pull from a directory that is partly packed without having to worry about missing objects due to pack-file name clashes.
2005-07-03Add "--non-empty" flag to git-pack-objectsLibravatar Linus Torvalds1-0/+7
It skips writing the pack-file if it ends up being empty.
2005-07-03Add "--incremental" flag to git-pack-objectsLibravatar Linus Torvalds1-1/+9
It won't add an object that is already in a pack to the new pack.
2005-06-29[PATCH] assorted delta code cleanupLibravatar Nicolas Pitre1-1/+1
This is a wrap-up patch including all the cleanups I've done to the delta code and its usage. The most important change is the factorization of the delta header handling code. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-28Make git pack files use little-endian size encodingLibravatar Linus Torvalds1-21/+8
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-28[PATCH] Emit base objects of a delta chain when the delta is output.Libravatar Junio C Hamano1-5/+20
Deltas are useless by themselves and when you use them you need to get to their base objects. A base object should inherit recency from the most recent deltified object that is based on it and that is what this patch teaches git-pack-objects. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-28[PATCH] Fix unpack-objects for header length information.Libravatar Junio C Hamano1-3/+3
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-22/+62
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-28git-pack-objects: add "--stdout" flag to write the pack file to stdoutLibravatar Linus Torvalds1-6/+15
This also suppresses creation of the index file.
2005-06-28Teach packing about "tag" objectsLibravatar Linus Torvalds1-13/+15
(And teach sha1_file and unpack-object know how to unpack them too, of course)
2005-06-27[PATCH] Enhance sha1_file_size() into sha1_object_info()Libravatar Junio C Hamano1-22/+16
This lets us eliminate one use of map_sha1_file() outside sha1_file.c, to bring us one step closer to the packed GIT. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27[PATCH] Remove "delta" object representation.Libravatar Junio C Hamano1-1/+1
Packed delta files created by git-pack-objects seems to be the way to go, and existing "delta" object handling code has exposed the object representation details to too many places. Remove it while we refactor code to come up with a proper interface in sha1_file.c. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26csum-file interface updates: return resulting SHA1Libravatar Linus Torvalds1-3/+5
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-55/+11
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-pack-objects: use name information (if any) to sort objects for packing.Libravatar Linus Torvalds1-4/+23
This is incredibly cheezy. But it's cheap, and it works pretty well.
2005-06-26git-pack-objects: do the delta search in reverse size orderLibravatar Linus Torvalds1-12/+16
Starting from big objects and going backwards means that we end up picking a delta that goes from a bigger object to a smaller one. That's advantageous for two reasons: the bigger object is likely the newer one (since things tend to grow, rather than shrink), and doing a delete tends to be smaller than doing an add. So the deltas don't tend to be top-of-tree, and the packed end result is just slightly smaller.
2005-06-26Fix object packing/unpacking.Libravatar Linus Torvalds1-5/+5
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-2/+4
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-25Add "--depth=N" parameter to git-pack-objects to limit maximum delta depthLibravatar Linus Torvalds1-7/+17
It too defaults to 10. A nice round random number.
2005-06-25git-pack-objects: make "--window=x" semantics more logical.Libravatar Linus Torvalds1-4/+4
A zero disables delta generation (like before), but we make the window be one bigger than specified, since we use one entry for the one to be tested (it used to be that "--window=1" was meaningless, since we'd have used up the single-entry window with the entry to be tested, and had no chance of actually ever finding a delta). The default window remains at 10, but now it really means "test the 10 closest objects", not "test the 9 closest objects".
2005-06-25Add a "max_size" parameter to diff_delta()Libravatar Linus Torvalds1-10/+12
Anything that generates a delta to see if two objects are close usually isn't interested in the delta ends up being bigger than some specified size, and this allows us to stop delta generation early when that happens.
2005-06-25Fix delta "sliding window" codeLibravatar Linus Torvalds1-4/+5
When Junio fixed the lack of a successful error code from try_delta(), that uncovered an off-by-one error in the caller. Also, some testing made it clear that we now find a lot more deltas, because we used to (incorrectly) break early on bogus "failure" cases.
2005-06-25[PATCH] (patchlet) pack-objects.c: try_delta()Libravatar Junio C Hamano1-0/+1
Return value of try_delta is checked for negativeness, but the success path does not return anything, letting compiler warn and presumably return garbage. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25git-pack-objects: mark the delta packing with a 'D'.Libravatar Linus Torvalds1-0/+1
When writing a delta, we take the real type from the object we're doing the delta against, and just write a 'D' as the type of the current object.
2005-06-25git-pack-objects: fix typoLibravatar Linus Torvalds1-1/+1
("<" should be "=")
2005-06-25git-pack-objects: create a packed object representation.Libravatar Linus Torvalds1-0/+403
This is kind of like a tar-ball for a set of objects, ready to be shipped off to another end. Alternatively, you could use is as a packed representation of the object database directly, if you changed "read_sha1_file()" to read these kinds of packs. The latter is partiularly useful to generate a "packed history", ie you could pack up your old history efficiently, but still have it available (at a performance hit, of course). I haven't actually written an unpacker yet, so the end result has not been verified in any way yet. I obviously always write bug-free code, so it just has to work, no?