From dc06dc880013d48f2b09c6b4295419382f3b8230 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Thu, 11 Feb 2016 17:26:44 -0500 Subject: list-objects: drop name_path entirely In the previous commit, we left name_path as a thin wrapper around a strbuf. This patch drops it entirely. As a result, every show_object_fn callback needs to be adjusted. However, none of their code needs to be changed at all, because the only use was to pass it to path_name(), which now handles the bare strbuf. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- reachable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'reachable.c') diff --git a/reachable.c b/reachable.c index 69fa6851da..4379d1ac79 100644 --- a/reachable.c +++ b/reachable.c @@ -36,7 +36,7 @@ static int add_one_ref(const char *path, const unsigned char *sha1, int flag, vo * The traversal will have already marked us as SEEN, so we * only need to handle any progress reporting here. */ -static void mark_object(struct object *obj, const struct name_path *path, +static void mark_object(struct object *obj, struct strbuf *path, const char *name, void *data) { update_progress(data); -- cgit v1.2.3 From 2824e1841b99393d2469c495253d547c643bd8f1 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Thu, 11 Feb 2016 17:28:36 -0500 Subject: list-objects: pass full pathname to callbacks When we find a blob at "a/b/c", we currently pass this to our show_object_fn callbacks as two components: "a/b/" and "c". Callbacks which want the full value then call path_name(), which concatenates the two. But this is an inefficient interface; the path is a strbuf, and we could simply append "c" to it temporarily, then roll back the length, without creating a new copy. So we could improve this by teaching the callsites of path_name() this trick (and there are only 3). But we can also notice that no callback actually cares about the broken-down representation, and simply pass each callback the full path "a/b/c" as a string. The callback code becomes even simpler, then, as we do not have to worry about freeing an allocated buffer, nor rolling back our modification to the strbuf. This is theoretically less efficient, as some callbacks would not bother to format the final path component. But in practice this is not measurable. Since we use the same strbuf over and over, our work to grow it is amortized, and we really only pay to memcpy a few bytes. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- reachable.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'reachable.c') diff --git a/reachable.c b/reachable.c index 4379d1ac79..9b0295469f 100644 --- a/reachable.c +++ b/reachable.c @@ -36,15 +36,14 @@ static int add_one_ref(const char *path, const unsigned char *sha1, int flag, vo * The traversal will have already marked us as SEEN, so we * only need to handle any progress reporting here. */ -static void mark_object(struct object *obj, struct strbuf *path, - const char *name, void *data) +static void mark_object(struct object *obj, const char *name, void *data) { update_progress(data); } static void mark_commit(struct commit *c, void *data) { - mark_object(&c->object, NULL, NULL, data); + mark_object(&c->object, NULL, data); } struct recent_data { -- cgit v1.2.3