ba002f3 (builtin-fsck: move common object checking code to fsck.c) did
more than what it claimed to. Most notably, it wrongly made an empty tree
object an error by pretending to only move code from fsck_tree() in
builtin-fsck.c to fsck_tree() in fsck.c, but in fact adding a bogus check
to barf on an empty tree.
An empty tree object is _unusual_. Recent porcelains try reasonably hard
not to let the user create a commit that contains such a tree. Perhaps
warning about them in git-fsck may have some merit.
However, being unusual and being errorneous are two quite different
things. This is especially true now we seem to use the same
fsck_$object() code in places other than git-fsck itself. For example,
receive-pack should not reject unusual objects, even if it would be a good
idea to tighten it to reject incorrect ones.
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
* I've wasted a few hours tonight hunting for random breakages in "git
push", the symptom of which is "fatal: unresolved deltas left after
unpacking." I was hoping this patch would fix it, but it seems that
the problem is elsewhere.
I'll revert the following two commits for now:
d5ef408 (unpack-objects: prevent writing of inconsistent objects)
28f72a0 (receive-pack: use strict mode for unpacking objects)
as I have verified that running with receive.fsckobjects set to false
fixes the issues for me, and the repository at the receiving end (both
before and after the push) pass git-fsck without problems. Needless to
say, I am not a happy camper right now.
fsck.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fsck.c b/fsck.c
index 6883d1b..797e317 100644
--- a/fsck.c
+++ b/fsck.c
@@ -155,8 +155,6 @@ static int fsck_tree(struct tree *item, int strict, fsck_error error_func)
o_mode = 0;
o_name = NULL;
o_sha1 = NULL;
- if (!desc.size)
- return error_func(&item->object, FSCK_ERROR, "empty tree");
while (desc.size) {
unsigned mode;
--
1.5.4.3.529.gb25fb
--
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
