According to sys/paramh.h it's a "BSD name" for values defined in <limits.h>. Besides PATH_MAX seems to be more commonly used. Signed-off-by: Jonas Fonseca <firstname.lastname@example.org> Signed-off-by: Junio C Hamano <email@example.com>
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 <firstname.lastname@example.org> Signed-off-by: Junio C Hamano <email@example.com>
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 <firstname.lastname@example.org> Signed-off-by: Junio C Hamano <email@example.com>
This adds "assume unchanged" logic, started by this message in the list discussion recently: <Pine.LNX.firstname.lastname@example.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 <email@example.com>
If the index records an insanely long symbolic link, copying into the temporary would overflow the buffer (noticed by Mark Wooding). Because read_sha1_file() terminates the returned buffer with NUL since late May 2005, there is no reason to copy it anymore. Signed-off-by: Junio C Hamano <firstname.lastname@example.org>
Signed-off-by: Alex Riesen <email@example.com> Signed-off-by: Junio C Hamano <firstname.lastname@example.org>
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 <email@example.com>
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 <firstname.lastname@example.org>
The symlink case had never worked, and the file case was broken by the O_EXCL change because the error return changed from EISDIR to EEXIST. Fix both problems by just moving the test for an existing directory to a more logical place.
We should always have unlinked any old ones before, but this just makes sure that we never over-write any old file. A quick "grep" now shows that all the core tools that open files for writing use O_EXCL, ie we never overwrite an existing file in place.
IIRC our strategy was to let the users' umask take care of the final mode bits. This patch fixes places that deviate from it. Signed-off-by: Junio C Hamano <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
The merge stuff will want it soon, and we don't want to duplicate all the work..