summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2005-06-28[PATCH] Bugfix: initialize pack_base to NULL.Libravatar Junio C Hamano1-0/+1
This was causing random segfaults, because use_packed_git() got confused by random garbage there. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-28[PATCH] Adjust fsck-cache to packed GIT and alternate object pool.Libravatar Junio C Hamano1-4/+16
The fsck-cache complains if objects referred to by files in .git/refs/ or objects stored in files under .git/objects/??/ are not found as stand-alone SHA1 files (i.e. found in alternate object pools GIT_ALTERNATE_OBJECT_DIRECTORIES or packed archives stored under .git/objects/pack). Although this is a good semantics to maintain consistency of a single .git/objects directory as a self contained set of objects, it sometimes is useful to consider it is OK as long as these "outside" objects are available. This commit introduces a new flag, --standalone, to git-fsck-cache. When it is not specified, connectivity checks and .git/refs pointer checks are taught that it is OK when expected objects do not exist under .git/objects/?? hierarchy but are available from an packed archive or in an alternate object pool. 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 Torvalds4-73/+174
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-28csum-file: add "sha1fd()" to create a SHA1 csum file from an existing file ↵Libravatar Linus Torvalds2-0/+21
descriptor We'll use this soon to write pack-files to stdout.
2005-06-28Duh. Fix transposed characters in git-pull-scriptLibravatar Linus Torvalds1-1/+1
I'd stupidly only tested the non-branch-name version.
2005-06-28Teach packing about "tag" objectsLibravatar Linus Torvalds3-14/+23
(And teach sha1_file and unpack-object know how to unpack them too, of course)
2005-06-28[PATCH] git-cat-file: '-s' to find out object size.Libravatar Junio C Hamano2-6/+19
We use sha1_object_info() now, and getting size is also trivial. I admit that this is more of "because we can" not "because I see immediate need for it", though. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-28[PATCH] git-cat-file: use sha1_object_info() on '-t'.Libravatar Junio C Hamano1-6/+4
When trying to find out the type of the object, there is no need to uncompress the whole object. Just use sha1_object_info(). Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-28[PATCH] Obtain sha1_file_info() for deltified pack entry properly.Libravatar Junio C Hamano1-4/+69
The initial one was not doing enough to figure things out without uncompressing too much. It also fixes a potential segfault resulting from missing use_packed_git() call. We would need to introduce unuse_packed_git() call and do proper use counting to figure out when it is safe to unmap, but currently we do not unmap packed file yet. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27Teach git-pull-script about pulling tagsLibravatar Linus Torvalds1-2/+7
2005-06-27Fix another test that broke with the recent git-init-db updateLibravatar Linus Torvalds1-1/+0
t5300-pack-object.sh test 8 expected to have to create the "pack" directory itself, and was unhappy when it already existed.
2005-06-27[PATCH] Skip writing out sha1 files for objects in packed git.Libravatar Junio C Hamano1-12/+27
Now, there's still a misfeature there, which is that when you create a new object, it doesn't check whether that object already exists in the pack-file, so you'll end up with a few recent objects that you really don't need (notably tree objects), and this patch fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27[PATCH] replace sha1sum with sum in t/t1002Libravatar Mark Allen1-15/+32
This replaces sha1sum(1) with sum(1) in t/t1002. GNU sum(1) runs in "BSD compatibility" mode by default, and not all systems have GNU coreutils. On any system without GNU coreutils (or sha1sum) t1002 will fail. This patch should make t1002 complete successfully everywhere that sum(1) runs. I've tested this on Darwin and Linux; it works on both platforms. Signed-off-by: Mark Allen <mrallen1@yahoo.com> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27Fix up test that counted subdirectories in ".git/objects"Libravatar Linus Torvalds1-3/+3
Now there are 257 of them (256 numeric ones, and the new "pack" directory)
2005-06-27git-init-db: create "pack" subdirectory under objectsLibravatar Linus Torvalds1-0/+2
Don't make the user have to mkdir it just because he's excited about the new object pack functionality, do it for him.
2005-06-27Merge rsync://rsync.kernel.org/pub/scm/gitk/gitkLibravatar Linus Torvalds1-139/+447
2005-06-27csum-file: fix missing buf pointer updateLibravatar Linus Torvalds1-0/+1
This would create broken pack archives for anything nontrivial.
2005-06-27[PATCH] Teach read_sha1_file() and friends about packed git object store.Libravatar Junio C Hamano2-12/+458
GIT_OBJECT_DIRECTORY and GIT_ALTERNATE_OBJECT_DIRECTORIES can have the "pack" subdirectory that houses "packed GIT" files produced by git-pack-objects (e.g. .git/objects/pack/foo.pack and .git/objects/pack/foo.idx; always store them as pairs). The following functions in sha1_file.c can then read object contents from such packed file: - sha1_object_info() - has_sha1_file() - read_sha1_file() Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27[PATCH] Enhance sha1_file_size() into sha1_object_info()Libravatar Junio C Hamano4-31/+27
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 Hamano25-948/+22
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-27[PATCH] git-ssh-pull: commit-id consistencyLibravatar Sven Verdoolaege2-5/+15
In contrast to other plumbing tools, git-ssh-push only allow a very restrictive form of commit-id filenames. This patch removes this restriction. Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27git-checkout-script: use "--verify --revs-only" to parse revsLibravatar Linus Torvalds1-1/+1
Sven Verdoolaege points out that I added the --verify option to git-rev-parse exactly for things like this, but didn't update the users.
2005-06-27Add a menu item for creating tags.Libravatar Paul Mackerras1-43/+140
2005-06-27Fix a bug where we would corrupt the stuff read from git-rev-list.Libravatar Paul Mackerras1-2/+7
If we have a very long commit message, and we end up getting a bufferfull of data from git-rev-list that all belongs to one commit, we ended up throwing away the data from a previous read that should have been included. The result was a error message about not being able to parse the output of git-rev-list. Also, if the git-rev-list output that we can't parse is long, only put the first 80 chars in the error message. Otherwise we end up with an enormous error window.
2005-06-27Add a menu entry for generating a patch between any two commits.Libravatar Paul Mackerras1-0/+87
2005-06-26csum-file interface updates: return resulting SHA1Libravatar Linus Torvalds4-16/+26
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-27Fix behaviour in the case where we have no commits to display.Libravatar Paul Mackerras1-10/+17
I had code in there to put "No commits selected" on the canvas but it needed some globals.
2005-06-26git-pack-objects: write the pack files with a SHA1 csumLibravatar Linus Torvalds5-62/+158
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-26Add "--pretty=full" format that also shows committer.Libravatar Linus Torvalds4-32/+25
Also move the common implementation of parsing the --pretty argument format into commit.c rather than having duplicates in diff-tree.c and rev-list.c.
2005-06-26Add git-verify-tag scriptLibravatar Jan Harkes1-0/+9
Here is a script to simplify validating the gpg signature created by git-tag-script. Might be useful to add to the git tree so that people don't have to search for the right post in the git mailinglist archives
2005-06-27Check for the existence of the git directory on startup.Libravatar Paul Mackerras1-1/+11
Check that $GIT_DIR (or .git, if GIT_DIR is not set) is a directory. This means we can give a more informative error message if the user runs gitk somewhere that isn't a git repository.
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-26Ooh. Make git-rev-list --object associate a name with objects.Libravatar Linus Torvalds2-9/+11
The name isn't unique, it's just the first name that object is reached through, so it's really nothing more than a hint.
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-26[PATCH] Add git-relink-script to fix up missing hardlinksLibravatar Ryan Anderson2-1/+174
This will scan 2 or more object repositories and look for common objects, check if they are hardlinked, and replace one with a hardlink to the other if not. This version warns when skipping files because of size differences, and handle more than 2 repositories automatically. Signed-off-by: Ryan Anderson <ryan@michonline.com> Cheered-on-by: Jeff Garzik <jgarzik@pobox.com> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26git-rev-parse: add "--not" flag to mark subsequent heads negativeLibravatar Linus Torvalds1-15/+15
If you have two lists of heads, and you want to see ones reachable from list $a but not from list $b, just do git-rev-list $(git-rev-parse $a --not $b) which is useful for both bisecting (where "b" would be the list of known good revisions, and "a" would be the latest found bad head) and for just seeing what the difference between two sets of heads are if you want to generate a pack-file for the difference.
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 Torvalds2-62/+49
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 Hamano3-18/+261
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 Torvalds7-17/+28
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-25[PATCH] Add a bit of developer documentation to pull.hLibravatar Junio C Hamano1-6/+15
Describe what to implement in fetch() and fetch_ref() for pull backend writers a bit better. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] http-pull: documentation updates.Libravatar Junio C Hamano1-2/+4
Describe -w option. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] Fix oversimplified optimization for add_cache_entry().Libravatar Junio C Hamano4-17/+43
An earlier change to optimize directory-file conflict check broke what "read-tree --emu23" expects. This is fixed by this commit. (1) Introduces an explicit flag to tell add_cache_entry() not to check for conflicts and use it when reading an existing tree into an empty stage --- by definition this case can never introduce such conflicts. (2) Makes read-cache.c:has_file_name() and read-cache.c:has_dir_name() aware of the cache stages, and flag conflict only with paths in the same stage. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] git-merge-one-file-script: do not misinterpret rm failure.Libravatar Junio C Hamano1-2/+5
When a merge adds a file DF and removes a directory there by deleting a path DF/DF, git-merge-one-file-script can be called for the removal of DF/DF when the path DF is already created by "git-read-tree -m -u". When this happens, we get confused by a failure return from 'rm -f -- "$4"' (where $4 is DF/DF); finding file DF there the "rm -f" command complains that DF is not a directory. What we want to ensure is that there is no file DF/DF in this case. Avoid getting ourselves confused by first checking if there is a file, and only then try to remove it (and check for failure from the "rm" command). Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] Add more tests for read-tree --emu23.Libravatar Junio C Hamano2-14/+150
This adds more tests for --emu23. One is to show how it can carry forward more local changes than the straightforward two-way fast forward, and another is to show the recent overeager optimization of directory/file conflict check broke things, which will be fixed in the next commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>