summaryrefslogtreecommitdiff
path: root/cache-tree.c
AgeCommit message (Collapse)AuthorFilesLines
2006-10-14Add hash_sha1_file()Libravatar Rene Scharfe1-6/+2
Most callers of write_sha1_file_prepare() are only interested in the resulting hash but don't care about the returned file name or the header. This patch adds a simple wrapper named hash_sha1_file() which does just that, and converts potential callers. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23Convert memcpy(a,b,20) to hashcpy(a,b).Libravatar Shawn Pearce1-3/+3
This abstracts away the size of the hash values when copying them from memory location to memory location, much as the introduction of hashcmp abstracted away hash value comparsion. A few call sites were using char* rather than unsigned char* so I added the cast rather than open hashcpy to be void*. This is a reasonable tradeoff as most call sites already use unsigned char* and the existing hashcmp is also declared to be unsigned char*. [jc: Splitted the patch to "master" part, to be followed by a patch for merge-recursive.c which is not in "master" yet. Fixed the cast in the latter hunk to combine-diff.c which was wrong in the original. Also converted ones left-over in combine-diff.c, diff-lib.c and upload-pack.c ] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-07Merge branch 'jc/gitlink' into nextLibravatar Junio C Hamano1-0/+26
* jc/gitlink: write-tree: --prefix=<path> read-tree: --prefix=<path>/ option.
2006-05-03cache-tree: a bit more debugging support.Libravatar Junio C Hamano1-2/+6
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-01write-tree: --prefix=<path>Libravatar Junio C Hamano1-0/+26
The "bind" commit can express an aggregation of multiple projects into a single commit. In such an organization, there would be one project, root of whose tree object is at the same level of the root of the aggregated projects, and other projects have their toplevel in separate subdirectories. Let's call that root level project the "primary project", and call other ones just "subprojects". You would first read-tree the primary project, and then graft the subprojects under their appropriate location using read-tree --prefix=<subdir>/ repeatedly. To write out a tree object from such an index for a subproject, write-tree --prefix=<subdir>/ is used. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-01cache-tree: replace a sscanf() by two strtol() callsLibravatar Johannes Schindelin1-1/+10
On one of my systems, sscanf() first calls strlen() on the buffer. But this buffer is not terminated by NUL. So git crashed. strtol() does not share that problem, as it stops reading after the first non-digit. [jc: original patch was wrong and did not read the cache-tree structure correctly; this has been fixed up and tested minimally with fsck-objects. ] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-27cache-tree.c: typefixLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-27cache_tree_update: give an option to update cache-tree only.Libravatar Junio C Hamano1-5/+15
When the extra "dryrun" parameter is true, cache_tree_update() recomputes the invalid entry but does not actually creates new tree object. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-27read-tree: teach 1-way merege and plain read to prime cache-tree.Libravatar Junio C Hamano1-3/+8
This teaches read-tree to fully populate valid cache-tree when reading a tree from scratch, or reading a single tree into an existing index, reusing only the cached stat information (i.e. one-way merge). We have already taught update-index about cache-tree, so "git checkout" followed by updates to a few path followed by a "git commit" would become very efficient. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-25cache-tree: sort the subtree entries.Libravatar Junio C Hamano1-26/+66
Not that this makes practical performance difference; the kernel tree for example has 200 or so directories that have subdirectory, and the largest ones have 57 of them (fs and drivers). With a test to apply 600 patches with git-apply and git-write-tree, this did not make more than one per-cent of a difference, but it is a good cleanup. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-24index: make the index file format extensible.Libravatar Junio C Hamano1-82/+26
... and move the cache-tree data into it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-24cache-tree: protect against "git prune".Libravatar Junio C Hamano1-1/+1
We reused the cache-tree data without verifying the tree object still exists. Recompute in cache_tree_update() an otherwise valid cache-tree entry when the tree object disappeared. This is not usually a problem, but theoretically without this fix things can break when the user does something like this: - read-index from a side branch - write-tree the result - remove the side branch with "git branch -D" - remove the unreachable objects with "git prune" - write-tree what is in the index. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-23Add cache-tree.Libravatar Junio C Hamano1-0/+519
The cache_tree data structure is to cache tree object names that would result from the current index file. The idea is to have an optional file to record each tree object name that corresponds to a directory path in the cache when we run write_cache(), and read it back when we run read_cache(). During various index manupulations, we selectively invalidate the parts so that the next write-tree can bypass regenerating tree objects for unchanged parts of the directory hierarchy. We could perhaps make the cache-tree data an optional part of the index file, but that would involve the index format updates, so unless we need it for performance reasons, the current plan is to use a separate file, $GIT_DIR/index.aux to store this information and link it with the index file with the checksum that is already used for index file integrity check. Signed-off-by: Junio C Hamano <junkio@cox.net>