summaryrefslogtreecommitdiff
path: root/lockfile.c
AgeCommit message (Collapse)AuthorFilesLines
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
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>
2007-04-21lockfile: record the primary process.Libravatar Junio C Hamano1-1/+5
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>
2007-04-03git-read-tree --index-output=<file>Libravatar Junio C Hamano1-3/+8
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>
2007-04-03_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.Libravatar Junio C Hamano1-0/+17
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>
2007-01-06Print a more accurate error message when we fail to create a lock file.Libravatar Steven Grimm1-1/+1
Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-04Merge branch 'maint'Libravatar Junio C Hamano1-1/+6
* maint: pack-check.c::verify_packfile(): don't run SHA-1 update on huge data Fix infinite loop when deleting multiple packed refs.
2007-01-03Fix infinite loop when deleting multiple packed refs.Libravatar Junio C Hamano1-1/+6
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>
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-1/+0
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>
2006-08-12Better error message when we are unable to lock the index fileLibravatar Junio C Hamano1-1/+9
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-06-09shared repository - add a few missing calls to adjust_shared_perm().Libravatar Junio C Hamano1-5/+10
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>
2006-06-06Make index file locking code reusable to others.Libravatar Junio C Hamano1-0/+57
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>