summaryrefslogtreecommitdiff
path: root/write-tree.c
AgeCommit message (Collapse)AuthorFilesLines
2006-04-27cache_tree_update: give an option to update cache-tree only.Libravatar Junio C Hamano1-1/+1
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-24index: make the index file format extensible.Libravatar Junio C Hamano1-11/+25
... and move the cache-tree data into it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-23Update write-tree to use cache-tree.Libravatar Junio C Hamano1-125/+12
The updated write-tree reads from $GIT_DIR/index.aux to pick up subtree objects information, updates the cache-tree with the index, and updates index.aux file after writing a tree out of the index file. Until update-index and other programs that modify the index are updated to maintain index.aux file, the index.aux file written by the last write-tree will become stale immediately after they update the index, which will result in the whole tree recomputation just like the original write-tree. The idea is to convert those commands to invalidate cache-tree whenever they touch the index entries, and write updated index.aux out. After the index is updated with them, write-tree will be able to reuse the parts of the cache-tree that have not been touched. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-04Use blob_, commit_, tag_, and tree_type throughout.Libravatar Peter Eriksen1-1/+2
This replaces occurences of "blob", "commit", "tag", and "tree", where they're really used as type specifiers, which we already have defined global constants for. Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-08"Assume unchanged" gitLibravatar Junio C Hamano1-1/+1
This adds "assume unchanged" logic, started by this message in the list discussion recently: <Pine.LNX.4.64.0601311807470.7301@g5.osdl.org> This is a workaround for filesystems that do not have lstat() that is quick enough for the index mechanism to take advantage of. On the paths marked as "assumed to be unchanged", the user needs to explicitly use update-index to register the object name to be in the next commit. You can use two new options to update-index to set and reset the CE_VALID bit: git-update-index --assume-unchanged path... git-update-index --no-assume-unchanged path... These forms manipulate only the CE_VALID bit; it does not change the object name recorded in the index file. Nor they add a new entry to the index. When the configuration variable "core.ignorestat = true" is set, the index entries are marked with CE_VALID bit automatically after: - update-index to explicitly register the current object name to the index file. - when update-index --refresh finds the path to be up-to-date. - when tools like read-tree -u and apply --index update the working tree file and register the current object name to the index file. The flag is dropped upon read-tree that does not check out the index entry. This happens regardless of the core.ignorestat settings. Index entries marked with CE_VALID bit are assumed to be unchanged most of the time. However, there are cases that CE_VALID bit is ignored for the sake of safety and usability: - while "git-read-tree -m" or git-apply need to make sure that the paths involved in the merge do not have local modifications. This sacrifices performance for safety. - when git-checkout-index -f -q -u -a tries to see if it needs to checkout the paths. Otherwise you can never check anything out ;-). - when git-update-index --really-refresh (a new flag) tries to see if the index entry is up to date. You can start with everything marked as CE_VALID and run this once to drop CE_VALID bit for paths that are modified. Most notably, "update-index --refresh" honours CE_VALID and does not actively stat, so after you modified a file in the working tree, update-index --refresh would not notice until you tell the index about it with "git-update-index path" or "git-update-index --no-assume-unchanged path". This version is not expected to be perfect. I think diff between index and/or tree and working files may need some adjustment, and there probably needs other cases we should automatically unmark paths that are marked to be CE_VALID. But the basics seem to work, and ready to be tested by people who asked for this feature. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-05write-tree: check extra arguments and die but be a bit more helpful.Libravatar Junio C Hamano1-1/+3
"git-write-tree junk" complains and dies, but it does not say what option it supports. Die with the usage string in such a case. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-28Make the rest of commands work from a subdirectory.Libravatar Junio C Hamano1-1/+4
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-07-29[PATCH] Trivial tidyupsLibravatar Petr Baudis1-2/+2
Simple whitespace-related tidyups ensuring style consistency. This is carried over from my old git-pb branch. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-11[PATCH] add --missing-ok option to write-treeLibravatar Bryan Larsen1-1/+13
This option allows a write-tree even if the referenced objects are not in the database. Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] git-write-tree doesn't check alternate directoriesLibravatar Jan Harkes1-5/+4
git-write-tree failed when referenced objects only exist in the GIT_ALTERNATE_OBJECT_DIRECTORIES path. Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-19[PATCH] cleanup of in-code namesLibravatar Alexey Nezhdanov1-4/+4
Fixes all in-code names that leaved during "big name change". Signed-off-by: Alexey Nezhdanov <snake@penza-gsm.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-11Merge with http://members.cox.net/junkio/git-jc.gitLibravatar Petr Baudis1-4/+31
2005-05-08write-tree is now willing to write empty treeLibravatar Petr Baudis1-4/+4
Cogito wants to be able to do some initial commit at the time of cg-init, which may be empty in case when cg-init is called in an empty tree.
2005-05-07Notice index that has path and path/file and refuse to write such a tree.Libravatar Junio C Hamano1-4/+31
Kay Sievers noticed that you can have both path and path/file in the cache and write-tree happily creates a tree object from such a state. Since a merge can result in such situation and the user should be able to see the situation by looking at the cache, rather than forbidding add_cache_entry() to create such conflicts, fix it by making write-tree refuse to write such an nonsensical tree. Here is a test case. -- test case -- $ ls -a ./ ../ $ git-init-db defaulting to local storage area $ date >path $ git-update-cache --add path $ rm path $ mkdir path $ date >path/file $ git-update-cache --add path/file $ git-ls-files --stage 100644 1738f2536b1201218c41153941da065cc26174c9 0 path 100644 620c72f1c1de15f56ff9d63d6d7cdc69e828f1e3 0 path/file $ git-ls-tree $(git-write-tree) ;# using old one 100644 blob 1738f2536b1201218c41153941da065cc26174c9 path 040000 tree ec116937f223e3df95aeac9f076902ae1618ae98 path $ ../git-write-tree ;# using new one You have both path and path/file fatal: write-tree: not able to write tree $ exit Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-04-26[PATCH] introduce xmalloc and xreallocLibravatar Christopher Li1-2/+2
Introduce xmalloc and xrealloc to die gracefully with a descriptive message when out of memory, rather than taking a SIGSEGV. Signed-off-by: Christopher Li<chrislgit@chrisli.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-25Simplify "write_sha1_file()" interfacesLibravatar Linus Torvalds1-19/+3
The write function now adds the header to the file by itself, so there is no reason to duplicate it among all the users any more.
2005-04-17[PATCH] fix for memory leak in write-tree.cLibravatar Brad Roberts1-4/+2
Fix a memory leak in write-tree.c, not freeing the directory buffer.
2005-04-15write-tree: refuse to write out trees with unmerged index entries.Libravatar Linus Torvalds1-0/+18
Of course, we can't even generate such an index yet, but give me some time. This is a cunning plan. Let's see if it actually works. (I feel like Wile E Coyote, waiting for the big rock to fall).
2005-04-15Convert the index file reading/writing to use network byte order.Libravatar Linus Torvalds1-2/+2
This allows using a git tree over NFS with different byte order, and makes it possible to just copy a fully populated repository and have the end result immediately usable (needing just a refresh to update the stat information).
2005-04-13[PATCH] Consolidate the error handlingLibravatar Petr Baudis1-2/+2
Now there is error() for "library" errors and die() for fatal "application" errors. usage() is now used strictly only for usage errors. Signed-off-by: Petr Baudis <pasky@ucw.cz>
2005-04-10Make "update-cache" a bit friendlier to use (and harder to mis-use).Libravatar Linus Torvalds1-2/+0
It now requires the "--add" flag before you add any new files, and a "--remove" file if you want to mark files for removal. And giving it the "--refresh" flag makes it just update all the files that it already knows about.
2005-04-09This implements the new "recursive tree" write-tree.Libravatar Linus Torvalds1-18/+63
It's got some debugging printouts etc still in it, but testing on the kernel seems to show that it does indeed fix the issue with huge tree files for each commit.
2005-04-08Use "-Wall -O2" for the compiler to get more warnings.Libravatar Linus Torvalds1-1/+1
And fix up the warnings that it pointed out. Let's keep the tree clean from early on. Not that the code is very beautiful anyway ;)
2005-04-07Add copyright notices.Libravatar Linus Torvalds1-0/+5
The tool interface sucks (especially "committing" information, which is just me doing everything by hand from the command line), but I think this is in theory actually a viable way of describing the world. So copyright it.
2005-04-07Initial revision of "git", the information manager from hellLibravatar Linus Torvalds1-0/+66