Not that anybody should ever get it, but somebody did (probably because
of a flaky filesystem, but whatever). And each time I see an error
message that I haven't seen before, I decide that next time it will look
better.
So this makes us write more relevant information about exactly which
file ended up having issues with a missing object. Which will tell
whether it was a tree object, for example, or just a regular file in the
index (and which one).
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
---
Not a big deal. But since somebody actually saw this message, let's just
make it more informative.
A lot of the "these can't happen unless you're seriously screwed" messages
aren't very good, because there is little upside when doing development.
But let's try to improve on them in case they happen in the future.
Not that this would make debugging much easier, but one thing that I
started wondering about was whether the problem Florian saw was about one
of the files he had done "git add" on, or whether it was a tree entry that
was the result of "find_subtree()".
cache-tree.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 16a65df..d917437 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -329,7 +329,8 @@ static int update_one(struct cache_tree *it,
entlen = pathlen - baselen;
}
if (mode != S_IFGITLINK && !missing_ok && !has_sha1_file(sha1))
- return error("invalid object %s", sha1_to_hex(sha1));
+ return error("invalid object %06o %s for '%.*s'",
+ mode, sha1_to_hex(sha1), entlen+baselen, path);
if (ce->ce_flags & CE_REMOVE)
continue; /* entry being removed */
--
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