Introduce an fsck API

[dscho]

No description provided.

[buildhive]

dscho » git #8 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

dscho » git #9 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

dscho » git #10 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

dscho » git #12 ABORTED

(what's this?)

[buildhive]

dscho » git #13 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

dscho » git #14 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

dscho » git #16 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

dscho » git #17 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

dscho » git #19 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

dscho » git #20 SUCCESS
This pull request looks good
(what's this?)

[dscho]

TODO:

• separate configuration for the different message IDs to allow inheriting from ~/.gitconfig, i.e. [fsck "receive"] taggerindent = ignore instead of [receive] fsckobjects = --tagger-ident
• report the message IDs, too
• add FSCK_IGNORE to FSCK_ERROR and FSCK_WARN, i.e. allow to ignore problems entirely
• support configuring git fsck

This will benefit from the fsck_options but be orthogonal otherwise:

• add an fsck option to avoid unpacking blobs (--quick mode?)

Maybe later, as an add-on:

• consider supporting a "white list" of SHA-1s to be assumed unproblematic, i.e. skipped when fsck'ing (could be a – possibly central – notes branch).

[buildhive]

dscho » git #22 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

dscho » git #23 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

dscho » git #24 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

dscho » git #26 SUCCESS
This pull request looks good
(what's this?)

[dscho]

add an fsck option to avoid unpacking blobs (--quick mode?)

@mhagger @peff I just made a simple experiment: in a fresh working directory, after touch empty && git add empty && git commit -m Empty, I ran git fsck after applying:

iff --git a/sha1_file.c b/sha1_file.c
index d7f1838..398c716 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2718,6 +2718,7 @@ void *read_sha1_file_extended(const unsigned char *sha1,
        const struct packed_git *p;
        const unsigned char *repl = lookup_replace_object_extended(sha1, flag);

+error("reading %s", sha1_to_hex(sha1));
        errno = 0;
        data = read_object(repl, type, size);
        if (data)

It did not report reading the blob at all, so I guess that we are actually already only testing for existence, not reading blobs???

[peff]

For loose objects, I think we end up in parse_object. For blobs it does not call into read_sha1_file, but instead into check_sha1_signature, which can stream the blob content.

[peff]

For packs, I think the process is more convoluted. We call into verify-pack, which reads each entry. For delta types, the entry doesn't have the real type (and I assume you want it to for the --quick feature). But you can use sha1_object_info to chase it down; it feels a little weird for fsck not to be working from first principles (e.g., what if our packfile or index is bogus and we mistakenly call something a blob that is not), but I think the point of fsck --quick would be to check the structural elements of the objects. You assume that the data isn't corrupted, etc, and if you're worried about that or get weird results, you run without --quick for a more thorough check.

[buildhive]

dscho » git #27 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

dscho » git #28 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

dscho » git #30 FAILURE
Looks like there's a problem with this pull request
(what's this?)