Browse files

Be marginally more careful about removing objects

The git philosophy when it comes to disk accesses is "Laugh in the face of

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

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 <>
Signed-off-by: Junio C Hamano <>
  • Loading branch information...
1 parent 50b8e35 commit 41f222e87a9062833712367d66114cae90b3769a Linus Torvalds committed with Junio C Hamano Oct 28, 2005
Showing with 3 additions and 0 deletions.
  1. +1 −0
  2. +1 −0
  3. +1 −0 prune-packed.c
@@ -15,6 +15,7 @@ do
git-fsck-objects --full --cache --unreachable "$@" |
sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
@@ -62,6 +62,7 @@ then
# all-into-one is used.
if test "$all_into_one" != '' && test "$existing" != ''
+ sync
( cd "$PACKDIR" &&
for e in $existing
@@ -71,6 +71,7 @@ int main(int argc, char **argv)
/* Handle arguments here .. */
+ sync();
return 0;

0 comments on commit 41f222e

Please sign in to comment.