I have two questions on "rev-list --objects".
(1) Would it make sense to have an extra flag to "rev-list
--objects" to make it list all the objects reachable from
commits listed in its output, even when some of them are
unchanged from UNINTERESTING commits? Right now, a pack
produced from "rev-list --objects A ^B" does not have enough
information to reproduce the tree associated with commit A.
(2) When "showing --objects", it lists the top-level tree node
with no name, which makes it indistinguishable from commit
objects by pack-objects, probably impacting the delta logic.
Would something like the following patch make sense, to name
such node "."; giving full-path not just the basename to
all named nodes would be even better, though.
---
# - master: git-format-patch: Prepare patches for e-mail submission.
# + (working tree)
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -179,7 +179,10 @@ static void show_commit_list(struct comm
die("unknown pending object %s (%s)", sha1_to_hex(obj->sha1),
name);
}
while (objects) {
- printf("%s %s\n", sha1_to_hex(objects->item->sha1),
objects->name);
+ const char *name = objects->name;
+ if (!*name && objects->item->type == tree_type)
+ name = ".";
+ printf("%s %s\n", sha1_to_hex(objects->item->sha1), name);
objects = objects->next;
}
}
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html