Re: [ANNOUNCE] Cogito-0.12

Subsystems: the rest

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [ANNOUNCE] Cogito-0.12

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:01

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;
 	}
 }

Re: [ANNOUNCE] Cogito-0.12

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:01


On Thu, 7 Jul 2005, Junio C Hamano wrote:
(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.
Well, that would certainly be possible. Just having a flag that disables 
"mark_tree_uninteresting()" would do it.
(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.
It doesn't impact the delta algorithm, because the objects are sorted by 
type first, so it never mixes up trees and commits.

But if you wanted to, something like this would be cleaner than your 
suggestion..

		Linus
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -154,7 +154,7 @@ static void show_commit_list(struct comm
 	while (list) {
 		struct commit *commit = pop_most_recent_commit(&list, SEEN);
 
-		p = process_tree(commit->tree, p, "");
+		p = process_tree(commit->tree, p, "tree");
 		if (process_commit(commit) == STOP)
 			break;
 	}
@@ -386,7 +386,7 @@ static struct commit *get_commit_referen
 			mark_tree_uninteresting(tree);
 			return NULL;
 		}
-		add_pending_object(object, "");
+		add_pending_object(object, "tree");
 		return NULL;
 	}
 
@@ -401,7 +401,7 @@ static struct commit *get_commit_referen
 			mark_blob_uninteresting(blob);
 			return NULL;
 		}
-		add_pending_object(object, "");
+		add_pending_object(object, "blob");
 		return NULL;
 	}
 	die("%s is unknown object", name);
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help