[PATCH] object: make add_object_array_with_mode a static function

[Ramsay Jones]

Signed-off-by: Ramsay Jones <***@ramsay1.demon.co.uk>
---

Hi Jeff,

I noticed that your 'jk/prune-mtime' branch also removes the only
call to the add_object_array_with_mode() function outside of the
object.c file; specifically commit 75ac69fa ("traverse_commit_list:
support pending blobs/trees with paths", 15-10-2014).

This patch (which was generated using the '--histogram' option to
format-patch), moves the function to before the definition of the
add_object_array() function (to avoid a forward declaration), and
makes it static.

If you need to re-roll this branch, could you please squash this
patch into the above commit. (again, assuming you have no plans
to add new external callers.)

[If new external callers are very likely in the future (i.e. this
function is an essential part of the object-array API), then it may
well not be worth doing this. (with perhaps a note in the commit
message? - dunno). Similar comments apply to the previous 'add_object'
patch as well!]

Thanks!

ATB,
Ramsay Jones


object.c | 10 +++++-----
object.h | 1 -
2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/object.c b/object.c
index df86bdd..e1ef3f9 100644
--- a/object.c
+++ b/object.c
@@ -339,16 +339,16 @@ void add_object_array_with_path(struct object *obj, const char *name,
array->nr = ++nr;
}

+static void add_object_array_with_mode(struct object *obj, const char *name, struct object_array *array, unsigned mode)
+{
+ add_object_array_with_path(obj, name, array, mode, NULL);
+}
+
void add_object_array(struct object *obj, const char *name, struct object_array *array)
{
add_object_array_with_mode(obj, name, array, S_IFINVALID);
}

-void add_object_array_with_mode(struct object *obj, const char *name, struct object_array *array, unsigned mode)
-{
- add_object_array_with_path(obj, name, array, mode, NULL);
-}
-
/*
* Free all memory associated with an entry; the result is
* in an unspecified state and should not be examined.
diff --git a/object.h b/object.h
index e5178a5..6416247 100644
--- a/object.h
+++ b/object.h
@@ -114,7 +114,6 @@ int object_list_contains(struct object_list *list, struct object *obj);

/* Object array handling .. */
void add_object_array(struct object *obj, const char *name, struct object_array *array);
-void add_object_array_with_mode(struct object *obj, const char *name, struct object_array *array, unsigned mode);
void add_object_array_with_path(struct object *obj, const char *name, struct object_array *array, unsigned mode, const char *path);

typedef int (*object_array_each_func_t)(struct object_array_entry *, void *);

[Jeff King]

Post by Ramsay Jones
I noticed that your 'jk/prune-mtime' branch also removes the only
call to the add_object_array_with_mode() function outside of the
support pending blobs/trees with paths", 15-10-2014).
This patch (which was generated using the '--histogram' option to
format-patch), moves the function to before the definition of the
add_object_array() function (to avoid a forward declaration), and
makes it static.
If you need to re-roll this branch, could you please squash this
patch into the above commit. (again, assuming you have no plans
to add new external callers.)

That seems reasonable. Because it's a code movement, I'd actually be
just as happy with it as a separate patch, where it's more obvious what
is going on.

Post by Ramsay Jones
[If new external callers are very likely in the future (i.e. this
function is an essential part of the object-array API), then it may
well not be worth doing this. (with perhaps a note in the commit
message? - dunno). Similar comments apply to the previous 'add_object'
patch as well!]

I actually wondered while writing this series whether anyone actually
_uses_ the mode in object_array (the new code I added sets it to the
appropriate value to be on the safe side, but traverse_commit_list does
not actually care about it).

Digging in the history, it looks like it is used for blob-to-blob diffs
(see 01618a3, "use mode of the tree in git-diff, if <tree>:<file> syntax
is used", 2007-04-22). And that still seems to be the case today. It's a
shame we have to keep such complication around for one single case
(especially because getting it wrong in other cases is likely to go
unnoticed for years), but I think it would probably require major
surgery to extract it.

I think we can take your patch a step further, though, like:

-- >8 --
Subject: [PATCH] drop add_object_array_with_mode

This is a thin compatibility wrapper around
add_pending_object_with_path. But the only caller is
add_object_array, which is itself just a thin compatibility
wrapper. There are no external callers, so we can just
remove this middle wrapper.

Noticed-by: Ramsay Jones <***@ramsay1.demon.co.uk>
Signed-off-by: Jeff King <***@peff.net>
---
I also wondered if add_pending_object_with_mode could get the same
treatment. But we _do_ use it in setup_revisions and friends when we
parse something like "HEAD:foo". It would be trivial here to call
add_pending_object_with_path instead, and actually feed "foo". That
would mean that "git rev-list --objects HEAD:foo" reported the pathname
"foo" alongside the object. Or if "foo" is a tree, all of its sub-parts
would be "foo/whatever" instead of just "whatever". That seems somewhat
sensible to me, but I would be unsurprised if it broke some weird corner
case that is expecting paths to be relative to the given tree.

object.c | 7 +------
object.h | 1 -
2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/object.c b/object.c
index df86bdd..23d6c96 100644
--- a/object.c
+++ b/object.c
@@ -341,12 +341,7 @@ void add_object_array_with_path(struct object *obj, const char *name,

void add_object_array(struct object *obj, const char *name, struct object_array *array)
{
- add_object_array_with_mode(obj, name, array, S_IFINVALID);
-}
-
-void add_object_array_with_mode(struct object *obj, const char *name, struct object_array *array, unsigned mode)
-{
- add_object_array_with_path(obj, name, array, mode, NULL);
+ add_object_array_with_path(obj, name, array, S_IFINVALID, NULL);
}

/*
diff --git a/object.h b/object.h
index e5178a5..6416247 100644
--- a/object.h
+++ b/object.h
@@ -114,7 +114,6 @@ int object_list_contains(struct object_list *list, struct object *obj);

/* Object array handling .. */
void add_object_array(struct object *obj, const char *name, struct object_array *array);
-void add_object_array_with_mode(struct object *obj, const char *name, struct object_array *array, unsigned mode);
void add_object_array_with_path(struct object *obj, const char *name, struct object_array *array, unsigned mode, const char *path);

typedef int (*object_array_each_func_t)(struct object_array_entry *, void *);

[Ramsay Jones]

[snip]

Post by Jeff King
I actually wondered while writing this series whether anyone actually
_uses_ the mode in object_array (the new code I added sets it to the
appropriate value to be on the safe side, but traverse_commit_list does
not actually care about it).
Digging in the history, it looks like it is used for blob-to-blob diffs
(see 01618a3, "use mode of the tree in git-diff, if <tree>:<file> syntax
is used", 2007-04-22). And that still seems to be the case today. It's a
shame we have to keep such complication around for one single case
(especially because getting it wrong in other cases is likely to go
unnoticed for years), but I think it would probably require major
surgery to extract it.

Yes, I'm always in favour of removing unused code! :-D

Post by Jeff King
-- >8 --
Subject: [PATCH] drop add_object_array_with_mode
This is a thin compatibility wrapper around
add_pending_object_with_path. But the only caller is
add_object_array, which is itself just a thin compatibility
wrapper. There are no external callers, so we can just
remove this middle wrapper.
---
I also wondered if add_pending_object_with_mode could get the same
treatment. But we _do_ use it in setup_revisions and friends when we
parse something like "HEAD:foo". It would be trivial here to call
add_pending_object_with_path instead, and actually feed "foo". That
would mean that "git rev-list --objects HEAD:foo" reported the pathname
"foo" alongside the object. Or if "foo" is a tree, all of its sub-parts
would be "foo/whatever" instead of just "whatever". That seems somewhat
sensible to me, but I would be unsurprised if it broke some weird corner
case that is expecting paths to be relative to the given tree.
object.c | 7 +------
object.h | 1 -
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/object.c b/object.c
index df86bdd..23d6c96 100644
--- a/object.c
+++ b/object.c
@@ -341,12 +341,7 @@ void add_object_array_with_path(struct object *obj, const char *name,
void add_object_array(struct object *obj, const char *name, struct object_array *array)
{
- add_object_array_with_mode(obj, name, array, S_IFINVALID);
-}
-
-void add_object_array_with_mode(struct object *obj, const char *name, struct object_array *array, unsigned mode)
-{
- add_object_array_with_path(obj, name, array, mode, NULL);
+ add_object_array_with_path(obj, name, array, S_IFINVALID, NULL);
}
/*
diff --git a/object.h b/object.h
index e5178a5..6416247 100644
--- a/object.h
+++ b/object.h
@@ -114,7 +114,6 @@ int object_list_contains(struct object_list *list, struct object *obj);
/* Object array handling .. */
void add_object_array(struct object *obj, const char *name, struct object_array *array);
-void add_object_array_with_mode(struct object *obj, const char *name, struct object_array *array, unsigned mode);
void add_object_array_with_path(struct object *obj, const char *name, struct object_array *array, unsigned mode, const char *path);
typedef int (*object_array_each_func_t)(struct object_array_entry *, void *);

Yep, this is a better patch.

Thanks!

ATB,
Ramsay Jones

[Junio C Hamano]

Post by Jeff King
-- >8 --
Subject: [PATCH] drop add_object_array_with_mode
...

Thanks. I think I picked up all incrementals in this thread, but
please holler if I missed anything.

[Jeff King]

Post by Junio C Hamano

Post by Jeff King
-- >8 --
Subject: [PATCH] drop add_object_array_with_mode
...

Thanks. I think I picked up all incrementals in this thread, but
please holler if I missed anything.

I just checked it (using Thomas's excellent "tbdiff" tool) and you have
everything. Thanks, and sorry for feeding it so piecemeal. :)

-Peff