summaryrefslogtreecommitdiff
path: root/checkout-index.c
AgeCommit message (Collapse)AuthorFilesLines
2006-08-12Better error message when we are unable to lock the index fileLibravatar Junio C Hamano1-1/+1
Most of the callers except the one in refs.c use the function to update the index file. Among the index writers, everybody except write-tree dies if they cannot open it for writing. This gives the function an extra argument, to tell it to die when it cannot create a new file as the lockfile. The only caller that does not have to die is write-tree, because updating the index for the cache-tree part is optional and not being able to do so does not affect the correctness. I think we do not have to be so careful and make the failure into die() the same way as other callers, but that would be a different patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10Avoid C99 initializersLibravatar Shawn Pearce1-8/+2
In a handful places, we use C99 structure and array initializers, which some compilers do not support. This can be handy when you are trying to compile GIT on a Solaris system that has an older C compiler, for example. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-08Close the index file between writing and committingLibravatar Johannes Schindelin1-1/+1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-06Make index file locking code reusable to others.Libravatar Junio C Hamano1-7/+6
The framework to create lockfiles that are removed at exit is first used to reliably write the index file, but it is applicable to other things, so stop calling it "cache_file". This also rewords a few remaining error message that called the index file "cache file". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-20Merge branch 'jc/cache-tree' into jc/dirwalk-n-cache-treeLibravatar Junio C Hamano1-0/+1
* jc/cache-tree: (24 commits) Fix crash when reading the empty tree fsck-objects: do not segfault on missing tree in cache-tree cache-tree: a bit more debugging support. read-tree: invalidate cache-tree entry when a new index entry is added. Fix test-dump-cache-tree in one-tree disappeared case. fsck-objects: mark objects reachable from cache-tree cache-tree: replace a sscanf() by two strtol() calls cache-tree.c: typefix test-dump-cache-tree: validate the cached data as well. cache_tree_update: give an option to update cache-tree only. read-tree: teach 1-way merege and plain read to prime cache-tree. read-tree: teach 1 and 2 way merges about cache-tree. update-index: when --unresolve, smudge the relevant cache-tree entries. test-dump-cache-tree: report number of subtrees. cache-tree: sort the subtree entries. Teach fsck-objects about cache-tree. index: make the index file format extensible. cache-tree: protect against "git prune". Add test-dump-cache-tree Use cache-tree in update-index. ...
2006-05-06Fix users of prefix_path() to free() only when necessaryLibravatar Johannes Schindelin1-2/+2
Unfortunately, prefix_path() sometimes returns a newly xmalloc()ed buffer, and in other cases it returns a substring! For example, when calling git update-index ./hello.txt prefix_path() returns "hello.txt", but does not allocate a new buffer. The original code only checked if the result of prefix_path() was different from what was passed in, and thusly trigger a segmentation fault. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05checkout-index: plug memory leak from prefix_path()Libravatar Junio C Hamano1-2/+11
prefix_path() sometimes allocates new memory and returns it, and other times returns the incoming path argument intact. The callers need to be a bit careful not to leak memory. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-24index: make the index file format extensible.Libravatar Junio C Hamano1-0/+1
... and move the cache-tree data into it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-02Fix sparse warnings about usage of 0 instead of NULLLibravatar Rene Scharfe1-1/+1
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05Add --temp and --stage=all options to checkout-index.Libravatar Shawn Pearce1-12/+74
Sometimes it is convient for a Porcelain to be able to checkout all unmerged files in all stages so that an external merge tool can be executed by the Porcelain or the end-user. Using git-unpack-file on each stage individually incurs a rather high penalty due to the need to fork for each file version obtained. git-checkout-index -a --stage=all will now do the same thing, but faster. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-01Teach git-checkout-index to read filenames from stdin.Libravatar Shawn Pearce1-0/+41
Since git-checkout-index is often used from scripts which may have a stream of filenames they wish to checkout it is more convenient to use --stdin than xargs. On platforms where fork performance is currently sub-optimal and the length of a command line is limited (*cough* Cygwin *cough*) running a single git-checkout-index process for a large number of files beats spawning it multiple times from xargs. File names are still accepted on the command line if --stdin is not supplied. Nothing is performed if no files are supplied on the command line or by stdin. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-08"Assume unchanged" gitLibravatar Junio C Hamano1-0/+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-13checkout-index: fix checking out specific path.Libravatar Junio C Hamano1-1/+1
3bd348aeea24709cd9be4b9d741f79b6014cd7e3 commit broke checking out specific paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-07checkout-index: allow checking out from higher stages.Libravatar Junio C Hamano1-18/+43
The new option, --stage=<n>, lets you copy out from an unmerged, higher stage. This is to help the new merge world order during a nontrivial merge. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-28checkout-index: work from subdirectory.Libravatar Junio C Hamano1-1/+11
With this, git-checkout-index from a subdirectory works as expected. Note that "git-checkout-index -a" checks out files only in the current directory and under. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Merge branch 'fixes'Libravatar Junio C Hamano1-48/+61
2005-10-17make checkout-index '-a' flag saner.Libravatar Linus Torvalds1-48/+61
The original semantics of pretending as if all files were specified where '-a' appeared and using only the flags given so far was too confusing. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-04Return error when not checking out an entry due to dirtiness.Libravatar Junio C Hamano1-2/+7
Without -f flag, 'git-checkout-index foo.c' issued an error message when foo.c already existed in the working tree and did not match index. However it did not return an error from the underlying checkout_entry() function and resulted in a successful exit(0). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07Big tool rename.Libravatar Junio C Hamano1-0/+151
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>