There are two places that diagnose the same kind of error in mark_object(),
that receives an object, the type the object is expected to be, and the
object that refers to it (IOW, the reason why we want to make sure that
the first object is in a good order). When the object that is referred to
is missing, we report "broken link from X; broken link to Y".
However, one of the two places, that is used much less often, said "broken
link from X; broken link from Y".
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
This rarely used codepath is triggered only when fsck_walk() calls this
function that is set as a callback in traverse_one_object() from one of
the type specific scanners, e.g. fsck_walk_tree(), and an object that is
referred to is of a wrong type, e.g. a tree entry with mode 100644 is
looked up with lookup_blob(), and the type of the named object is already
known to us to be something different. The look-up code issues an unrelated
error message in such a case, but then this codepath does not know what the
object name of the offending object was.
---
builtin/fsck.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 5ae0366..64f30d4 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -83,7 +83,7 @@ static int mark_object(struct object *obj, int type, void *data)
/* ... these references to parent->fld are safe here */
printf("broken link from %7s %s\n",
typename(parent->type), sha1_to_hex(parent->sha1));
- printf("broken link from %7s %s\n",
+ printf("broken link to %7s %s\n",
(type == OBJ_ANY ? "unknown" : typename(type)), "unknown");
errors_found |= ERROR_REACHABLE;
return 1;
--
1.7.6
--
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