summaryrefslogtreecommitdiff
path: root/checkout-index.c
AgeCommit message (Collapse)Author
2006-04-02Fix sparse warnings about usage of 0 instead of NULLRene Scharfe
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.Shawn Pearce
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.Shawn Pearce
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-09"Assume unchanged" gitJunio C Hamano
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-14checkout-index: fix checking out specific path.Junio C Hamano
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.Junio C Hamano
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-29checkout-index: work from subdirectory.Junio C Hamano
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-18Merge branch 'fixes'Junio C Hamano
2005-10-18make checkout-index '-a' flag saner.Linus Torvalds
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-05Return error when not checking out an entry due to dirtiness.Junio C Hamano
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-08Big tool rename.Junio C Hamano
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>