kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	d58e8d34b0	When locking in a symlinked repository, try to lock the original. In a working tree prepared in new-workdir (in contrib/), some files in .git/ directory are symbolic links to the original repository. The usual sequence of lock-write-rename would break the symbolic link. Ideally we should resolve relative symbolic link with maxdepth, but I do not want to risk too elaborate patch before 1.5.3 release, so this is a minimum and trivially obvious fix. new-workdir creates its symbolic links absolute, and does not link from a symlinked workdir, so this fix should suffice for now. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Sven Verdoolaege	9a4cbdca34	lockfile.c: schedule remove_lock_file only once. Removing a lockfile once should be enough. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	a6080a0a44	War on whitespace This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	5e635e3960	lockfile: record the primary process. The usual process flow is the main process opens and holds the lock to the index, does its thing, perhaps spawning children during the course, and then writes the resulting index out by releaseing the lock. However, the lockfile interface uses atexit(3) to clean it up, without regard to who actually created the lock. This typically leads to a confusing behaviour of lock being released too early when the child exits, and then the parent process when it calls commit_lockfile() finds that it cannot unlock it. This fixes the problem by recording who created and holds the lock, and upon atexit(3) handler, child simply ignores the lockfile the parent created. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	5e7f56ac33	git-read-tree --index-output=<file> This corrects the interface mistake of the previous one, and gives a command line parameter to the only plumbing command that currently needs it: "git-read-tree". We can add the calls to set_alternate_index_output() to other plumbing commands that update the index if/when needed. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	30ca07a249	_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file. When defined, this allows plumbing commands that update the index (add, apply, checkout-index, merge-recursive, mv, read-tree, rm, update-index, and write-tree) to write their resulting index to an alternative index file while holding a lock to the original index file. With this, git-commit that jumps the index does not have to make an extra copy of the index file, and more importantly, it can do the update while holding the lock on the index. However, I think the interface to let an environment variable specify the output is a mistake, as shown in the documentation. If a curious user has the environment variable set to something other than the file GIT_INDEX_FILE points at, almost everything will break. This should instead be a command line parameter to tell these plumbing commands to write the result in the named file, to prevent stupid mistakes. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Steven Grimm	f9e8a43a00	Print a more accurate error message when we fail to create a lock file. Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	1084b845d9	Fix infinite loop when deleting multiple packed refs. It was stupid to link the same element twice to lock_file_list and end up in a loop, so we certainly need a fix. But it is not like we are taking a lock on multiple files in this case. It is just that we leave the linked element on the list even after commit_lock_file() successfully removes the cruft. We cannot remove the list element in commit_lock_file(); if we are interrupted in the middle of list manipulation, the call to remove_lock_file_on_signal() will happen with a broken list structure pointed by lock_file_list, which would cause the cruft to remain, so not removing the list element is the right thing to do. Instead we should be reusing the element already on the list. There is already a code for that in lock_file() function in lockfile.c. The code checks lk->next and the element is linked only when it is not already on the list -- which is incorrect for the last element on the list (which has NULL in its next field), but if you read the check as "is this element already on the list?" it actually makes sense. We do not want to link it on the list again, nor we would want to set up signal/atexit over and over. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	85023577a8	simplify inclusion of system header files. This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	40aaae88ad	Better error message when we are unable to lock the index file 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>	18 years ago
Junio C Hamano	138086a725	shared repository - add a few missing calls to adjust_shared_perm(). There were a few calls to adjust_shared_perm() that were missing: - init-db creates refs, refs/heads, and refs/tags before reading from templates that could specify sharedrepository in the config file; - updating config file created it under user's umask without adjusting; - updating refs created it under user's umask without adjusting; - switching branches created .git/HEAD under user's umask without adjusting. This moves adjust_shared_perm() from sha1_file.c to path.c, since a few SIMPLE_PROGRAM need to call repository configuration functions which in turn need to call adjust_shared_perm(). sha1_file.c needs to link with SHA1 computation library which is usually not linked to SIMPLE_PROGRAM. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	021b6e4549	Make index file locking code reusable to others. 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>	19 years ago

13 Commits (7ab3cc70a6aad2e4f8ccaa98e5520aa126eaef8f)