summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: a9d7c95)
raw | patch | inline | side by side (parent: a9d7c95)
author | Junio C Hamano <gitster@pobox.com> | |
Tue, 20 Oct 2009 18:46:55 +0000 (11:46 -0700) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Tue, 20 Oct 2009 19:11:39 +0000 (12:11 -0700) |
Linus and other git developers from the early days trained their fingers
to type the command, every once in a while even without thinking, to check
the consistency of the repository back when the lower core part of the git
was still being developed. Developers who wanted to make sure that git
correctly dealt with packfiles could deliberately trigger their creation
and checked them after they were created carefully, but loose objects are
the ones that are written by various commands from random codepaths. It
made some technical sense to have a mode that checked only loose objects
from the debugging point of view for that reason.
Even for git developers, there no longer is any reason to type "git fsck"
every five minutes these days, worried that some newly created objects
might be corrupt due to recent change to git.
The reason we did not make "--full" the default is probably we trust our
filesystems a bit too much. At least, we trusted filesystems more than we
trusted the lower core part of git that was under development.
Once a packfile is created and we always use it read-only, there didn't
seem to be much point in suspecting that the underlying filesystems or
disks may corrupt them in such a way that is not caught by the SHA-1
checksum over the entire packfile and per object checksum. That trust in
the filesystems might have been a good tradeoff between fsck performance
and reliability on platforms git was initially developed on and for, but
it may not be true anymore as we run on many more platforms these days.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
to type the command, every once in a while even without thinking, to check
the consistency of the repository back when the lower core part of the git
was still being developed. Developers who wanted to make sure that git
correctly dealt with packfiles could deliberately trigger their creation
and checked them after they were created carefully, but loose objects are
the ones that are written by various commands from random codepaths. It
made some technical sense to have a mode that checked only loose objects
from the debugging point of view for that reason.
Even for git developers, there no longer is any reason to type "git fsck"
every five minutes these days, worried that some newly created objects
might be corrupt due to recent change to git.
The reason we did not make "--full" the default is probably we trust our
filesystems a bit too much. At least, we trusted filesystems more than we
trusted the lower core part of git that was under development.
Once a packfile is created and we always use it read-only, there didn't
seem to be much point in suspecting that the underlying filesystems or
disks may corrupt them in such a way that is not caught by the SHA-1
checksum over the entire packfile and per object checksum. That trust in
the filesystems might have been a good tradeoff between fsck performance
and reliability on platforms git was initially developed on and for, but
it may not be true anymore as we run on many more platforms these days.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/RelNotes-1.6.6.txt | patch | blob | history | |
Documentation/git-fsck.txt | patch | blob | history | |
builtin-fsck.c | patch | blob | history |
index 5f1fecb5ec4d1b7a1435991abd36ccbf615f4648..fa0e11a1806793bfef3e03df477f1cc5dbb0800d 100644 (file)
GIT v1.6.6 Release Notes
========================
+In this release, "git fsck" defaults to "git fsck --full" and checks
+packfiles, and because of this it will take much longer to complete
+than before. If you prefer a quicker check only on loose objects (the
+old default), you can say "git fsck --no-full". This has been
+supported by 1.5.4 and newer versions of git, so it is safe to write
+it in your script even if you use slightly older git on some of your
+machines.
+
In git 1.7.0, which is planned to be the release after 1.6.6, "git
push" into a branch that is currently checked out will be refused by
default.
(usability, bells and whistles)
+ * "git fsck" by default checks the packfiles (i.e. "--full" is the
+ default); you can turn it off with "git fsck --no-full".
+
* "git log --decorate" shows the location of HEAD as well.
(developers)
index 287c4fc5e07ea753c2a3d93bf6480f41aac8c9af..6fe9484da325fa1f72809937df263574ffe6fb9b 100644 (file)
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--full] [--strict] [--verbose] [--lost-found] [<object>*]
+ [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
DESCRIPTION
-----------
or $GIT_DIR/objects/info/alternates,
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
- object pools.
+ object pools. This is now default; you can turn it off
+ with --no-full.
--strict::
Enable more strict checking, namely to catch a file mode
diff --git a/builtin-fsck.c b/builtin-fsck.c
index c58b0e337ed434ffb90cfb5c80540531d94a4a6a..2d88e4570f8217beaf7f5400dc3c3a328222ebe8 100644 (file)
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
static int show_tags;
static int show_unreachable;
static int include_reflogs = 1;
-static int check_full;
+static int check_full = 1;
static int check_strict;
static int keep_cache_objects;
static unsigned char head_sha1[20];