Граф коммитов

16 Коммитов

Автор SHA1 Сообщение Дата
Steffen Prohaska ecf4831d89 Use is_absolute_path() in diff-lib.c, lockfile.c, setup.c, trace.c
Using the helper function to test for absolute paths makes porting easier.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-26 12:32:05 -08:00
Johannes Schindelin 4723ee992c Close files opened by lock_file() before unlinking.
This is needed on Windows since open files cannot be unlinked.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14 15:18:39 -08:00
Bradford C. Smith 5d5a7a6738 fully resolve symlinks when creating lockfiles
Make the code for resolving symlinks in lockfile.c more robust as
follows:

1. Handle relative symlinks
2. recursively resolve symlink chains up to 5

[jc: removed lstat/stat calls to do things stupid way]

Signed-off-by: Bradford C. Smith <bradford.carl.smith@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-27 00:02:05 -07:00
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>
2007-07-25 16:22:55 -07:00
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>
2007-07-13 08:55:15 -07:00
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>
2007-06-07 00:04:01 -07:00
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>
2007-04-21 11:55:23 -07:00
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>
2007-04-03 23:44:32 -07:00
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>
2007-04-03 23:44:32 -07:00
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>
2007-01-06 10:42:49 -08:00
Junio C Hamano e27e609bbf Merge branch 'maint'
* 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-04 22:28:21 -08:00
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>
2007-01-03 01:22:35 -08:00
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>
2006-12-20 09:51:35 -08:00
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>
2006-08-12 17:08:25 -07:00
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>
2006-06-09 22:15:50 -07:00
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>
2006-06-06 14:30:58 -07:00