From: Jeff King <peff@peff.net>
To: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Junio C Hamano <gitster@pobox.com>,
GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH] object: make add_object_array_with_mode a static function
Date: Sat, 18 Oct 2014 22:03:19 -0400 [thread overview]
Message-ID: <20141019020319.GB17908@peff.net> (raw)
In-Reply-To: <5442F56B.8020205@ramsay1.demon.co.uk>
On Sun, Oct 19, 2014 at 12:19:07AM +0100, Ramsay Jones wrote:
> 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.)
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.
> [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 <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jeff King <peff@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 *);
--
2.1.2.596.g7379948
next prev parent reply other threads:[~2014-10-19 2:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-18 23:19 [PATCH] object: make add_object_array_with_mode a static function Ramsay Jones
2014-10-19 2:03 ` Jeff King [this message]
2014-10-19 10:21 ` Ramsay Jones
2014-10-20 16:21 ` Junio C Hamano
2014-10-20 17:03 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141019020319.GB17908@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ramsay@ramsay1.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.