summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 50b8e35)
raw | patch | inline | side by side (parent: 50b8e35)
author | Linus Torvalds <torvalds@osdl.org> | |
Fri, 28 Oct 2005 16:45:53 +0000 (09:45 -0700) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Fri, 28 Oct 2005 21:25:02 +0000 (14:25 -0700) |
The git philosophy when it comes to disk accesses is "Laugh in the face of
danger".
Notably, since we never modify an existing object, we don't really care
that deeply about flushing things to disk, since even if the machine
crashes in the middle of a git operation, you can never really have lost
any old work. At most, you'd need to figure out the proper heads (which
git-fsck-objects can do for you) and re-do the operation.
However, there's two exceptions to this: pruning and repacking. Those
operations will actually _delete_ old objects that they know about in
other ways (ie that they just repacked, or that they have found in other
places).
However, since they actually modify old state, we should thus be a bit
more careful about them. If the machine crashes and the duplicate new
objects haven't been flushed to disk, you can actually be in trouble.
This is trivially stupid about it by calling "sync" before removing the
objects. Not very smart, but we're talking about special operations than
are usually done once a week if that.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
danger".
Notably, since we never modify an existing object, we don't really care
that deeply about flushing things to disk, since even if the machine
crashes in the middle of a git operation, you can never really have lost
any old work. At most, you'd need to figure out the proper heads (which
git-fsck-objects can do for you) and re-do the operation.
However, there's two exceptions to this: pruning and repacking. Those
operations will actually _delete_ old objects that they know about in
other ways (ie that they just repacked, or that they have found in other
places).
However, since they actually modify old state, we should thus be a bit
more careful about them. If the machine crashes and the duplicate new
objects haven't been flushed to disk, you can actually be in trouble.
This is trivially stupid about it by calling "sync" before removing the
objects. Not very smart, but we're talking about special operations than
are usually done once a week if that.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-prune.sh | patch | blob | history | |
git-repack.sh | patch | blob | history | |
prune-packed.c | patch | blob | history |
diff --git a/git-prune.sh b/git-prune.sh
index b28630cacfa035106b7980b395fc9c1f9b1509d1..ef31bd2a6824104ba401bffbe41ecd50a81780e9 100755 (executable)
--- a/git-prune.sh
+++ b/git-prune.sh
shift;
done
+sync
git-fsck-objects --full --cache --unreachable "$@" |
sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
diff --git a/git-repack.sh b/git-repack.sh
index 49547a77c75356fb12dc3c9451a8983e06f81240..d341966efba783b294792c9a13915982f70a1f73 100755 (executable)
--- a/git-repack.sh
+++ b/git-repack.sh
# all-into-one is used.
if test "$all_into_one" != '' && test "$existing" != ''
then
+ sync
( cd "$PACKDIR" &&
for e in $existing
do
diff --git a/prune-packed.c b/prune-packed.c
index 16685d1d8b25358f8df45a92262b4b0f6ea9cef5..26123f7f6bb8bf9cc7fc27905fe2b67d66646f05 100644 (file)
--- a/prune-packed.c
+++ b/prune-packed.c
/* Handle arguments here .. */
usage(prune_packed_usage);
}
+ sync();
prune_packed_objects();
return 0;
}