From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Date: Fri, 30 May 2008 08:54:46 -0700 Since the pack-files are now always created stably on disk, there is no need to sync() before pruning lose objects or old stale pack-files. Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> --- This literally just removes the syncs. The only thing they wanted to protect were the pack-files, that are now created stably. Yes, you can screw this up by doing direct filesystem operations on the pack-files (ie rsync/http walkers etc), but let's face it - those operations are pretty much fundamentally more problematic than anything we can do anyway, so I canno bring myself to care. Also, maybe I missed some case where we should fsync. I think this is all good, but having other people look at and think about this would be better still. builtin-prune-packed.c | 1 - builtin-prune.c | 1 - git-repack.sh | 1 - 3 files changed, 0 insertions(+), 3 deletions(-) diff --git a/builtin-prune-packed.c b/builtin-prune-packed.c index 23faf31..241afbb 100644 --- a/builtin-prune-packed.c +++ b/builtin-prune-packed.c @@ -85,7 +85,6 @@ int cmd_prune_packed(int argc, const char **argv, const char *prefix) /* Handle arguments here .. */ usage(prune_packed_usage); } - sync(); prune_packed_objects(opts); return 0; } diff --git a/builtin-prune.c b/builtin-prune.c index 25f9304..bd3d2f6 100644 --- a/builtin-prune.c +++ b/builtin-prune.c @@ -156,7 +156,6 @@ int cmd_prune(int argc, const char **argv, const char *prefix) mark_reachable_objects(&revs, 1); prune_object_dir(get_object_directory()); - sync(); prune_packed_objects(show_only); remove_temporary_files(); return 0; diff --git a/git-repack.sh b/git-repack.sh index 10f735c..072d1b4 100755 --- a/git-repack.sh +++ b/git-repack.sh @@ -125,7 +125,6 @@ then # We know $existing are all redundant. if [ -n "$existing" ] then - sync ( cd "$PACKDIR" && for e in $existing do -- 1.5.6.rc0.48.g5eea -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
