From: Junio C Hamano <gitster@pobox•com>
To: Jonathan Tan <jonathantanmy@google•com>
Cc: git@vger•kernel.org, peff@peff•net
Subject: Re: [PATCH v4 3/8] sha1_file: rename LOOKUP_REPLACE_OBJECT
Date: Wed, 21 Jun 2017 10:33:09 -0700 [thread overview]
Message-ID: <xmqqinjpqm96.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <6f6e8237db12ec2cd8fb4c8e2951bfc867a656a2.1497920092.git.jonathantanmy@google.com> (Jonathan Tan's message of "Mon, 19 Jun 2017 18:03:10 -0700")
Jonathan Tan <jonathantanmy@google•com> writes:
> The LOOKUP_REPLACE_OBJECT flag controls whether the
> lookup_replace_object() function is invoked by
> sha1_object_info_extended(), read_sha1_file_extended(), and
> lookup_replace_object_extended(), but it is not immediately clear which
> functions accept that flag.
>
> Therefore restrict this flag to only sha1_object_info_extended(),
> renaming it appropriately to OBJECT_INFO_LOOKUP_REPLACE and adding some
> documentation. Update read_sha1_file_extended() to have a boolean
> parameter instead, and delete lookup_replace_object_extended().
>
> parse_sha1_header() also passes this flag to
> parse_sha1_header_extended() since commit 46f0344 ("sha1_file: support
> reading from a loose object of unknown type", 2015-05-03), but that has
> had no effect since that commit. Therefore this patch also removes this
> flag from that invocation.
Yay, code reduction ;-).
> -/* object replacement */
> -#define LOOKUP_REPLACE_OBJECT 1
> -extern void *read_sha1_file_extended(const unsigned char *sha1, enum object_type *type, unsigned long *size, unsigned flag);
> +extern void *read_sha1_file_extended(const unsigned char *sha1,
> + enum object_type *type,
> + unsigned long *size, int lookup_replace);
In general, I'd hesitate to regress the API from "unsigned flag"
(that is easier to extend) to "int is_foo" (that will either have to
be reverted back to "unsigned flag", or an overlong parameter list
"int is_foo, int is_bar, int is_baz, ...").
But let's take this as-is and see how it evolves.
> @@ -3025,7 +3027,7 @@ int sha1_object_info(const unsigned char *sha1, unsigned long *sizep)
>
> oi.typep = &type;
> oi.sizep = sizep;
> - if (sha1_object_info_extended(sha1, &oi, LOOKUP_REPLACE_OBJECT) < 0)
> + if (sha1_object_info_extended(sha1, &oi, OBJECT_INFO_LOOKUP_REPLACE))
> return -1;
> return type;
> }
This changes the error behaviour slightly, doesn't it? Is it
guaranteed that sha1_object_info_extended() will never return
positive non-zero? Right now it appears that is the case, so
this probably is a justifiable simplification of a caller, but
given the real consumer of the _extended() API in cat-file.c
treats only negative as an error, we should be consistent.
I'd prefer to see this change _not_ made as part of this patch.
It may be OK to change this place and two callers in cat-file in a
follow-up patch though.
> @@ -3107,13 +3109,14 @@ static void *read_object(const unsigned char *sha1, enum object_type *type,
> void *read_sha1_file_extended(const unsigned char *sha1,
> enum object_type *type,
> unsigned long *size,
> - unsigned flag)
> + int lookup_replace)
> {
> void *data;
> const struct packed_git *p;
> const char *path;
> struct stat st;
> - const unsigned char *repl = lookup_replace_object_extended(sha1, flag);
> + const unsigned char *repl = lookup_replace ? lookup_replace_object(sha1)
> + : sha1;
>
> errno = 0;
> data = read_object(repl, type, size);
next prev parent reply other threads:[~2017-06-21 17:33 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-09 19:23 [RFC PATCH 0/4] Improvements to sha1_file Jonathan Tan
2017-06-09 19:23 ` [RFC PATCH 1/4] sha1_file: teach packed_object_info about typename Jonathan Tan
2017-06-12 20:55 ` Junio C Hamano
2017-06-09 19:23 ` [RFC PATCH 2/4] sha1_file: extract type and size from object_info Jonathan Tan
2017-06-10 7:01 ` Jeff King
2017-06-12 19:52 ` Jonathan Tan
2017-06-12 21:13 ` Jeff King
2017-06-09 19:23 ` [RFC PATCH 3/4] sha1_file: consolidate storage-agnostic object fns Jonathan Tan
2017-06-09 19:23 ` [RFC PATCH 4/4] sha1_file, fsck: add missing blob support Jonathan Tan
2017-06-13 21:05 ` [PATCH v2 0/4] Improvements to sha1_file Jonathan Tan
2017-06-13 21:05 ` [PATCH v2 1/4] sha1_file: teach packed_object_info about typename Jonathan Tan
2017-06-13 21:05 ` [PATCH v2 2/4] sha1_file: move delta base cache code up Jonathan Tan
2017-06-15 17:00 ` Junio C Hamano
2017-06-13 21:05 ` [PATCH v2 3/4] sha1_file: consolidate storage-agnostic object fns Jonathan Tan
2017-06-15 17:50 ` Junio C Hamano
2017-06-15 18:14 ` Jonathan Tan
2017-06-17 12:19 ` Jeff King
2017-06-19 4:18 ` Junio C Hamano
2017-06-13 21:06 ` [PATCH v2 4/4] sha1_file, fsck: add missing blob support Jonathan Tan
2017-06-15 18:34 ` Junio C Hamano
2017-06-15 20:31 ` Jonathan Tan
2017-06-15 20:52 ` Junio C Hamano
2017-06-15 20:39 ` [PATCH v3 0/4] Improvements to sha1_file Jonathan Tan
2017-06-15 20:39 ` [PATCH v3 1/4] sha1_file: teach packed_object_info about typename Jonathan Tan
2017-06-15 20:39 ` [PATCH v3 2/4] sha1_file: move delta base cache code up Jonathan Tan
2017-06-15 20:39 ` [PATCH v3 3/4] sha1_file: consolidate storage-agnostic object fns Jonathan Tan
2017-06-15 20:39 ` [PATCH v3 4/4] sha1_file, fsck: add missing blob support Jonathan Tan
2017-06-20 1:03 ` [PATCH v4 0/8] Improvements to sha1_file Jonathan Tan
2017-06-20 1:03 ` [PATCH v4 1/8] sha1_file: teach packed_object_info about typename Jonathan Tan
2017-06-20 1:03 ` [PATCH v4 2/8] sha1_file: rename LOOKUP_UNKNOWN_OBJECT Jonathan Tan
2017-06-21 17:22 ` Junio C Hamano
2017-06-21 17:34 ` Jonathan Tan
2017-06-20 1:03 ` [PATCH v4 3/8] sha1_file: rename LOOKUP_REPLACE_OBJECT Jonathan Tan
2017-06-21 17:33 ` Junio C Hamano [this message]
2017-06-20 1:03 ` [PATCH v4 4/8] sha1_file: move delta base cache code up Jonathan Tan
2017-06-20 1:03 ` [PATCH v4 5/8] sha1_file: refactor read_object Jonathan Tan
2017-06-21 17:58 ` Junio C Hamano
2017-06-20 1:03 ` [PATCH v4 6/8] sha1_file: improve sha1_object_info_extended Jonathan Tan
2017-06-24 12:45 ` Jeff King
2017-06-26 16:45 ` Jonathan Tan
2017-06-26 17:28 ` Junio C Hamano
2017-06-26 17:35 ` Jonathan Tan
2017-06-26 17:26 ` Junio C Hamano
2017-06-20 1:03 ` [PATCH v4 7/8] sha1_file: do not access pack if unneeded Jonathan Tan
2017-06-21 18:15 ` Junio C Hamano
2017-06-24 12:48 ` Jeff King
2017-06-24 18:41 ` Junio C Hamano
2017-06-24 20:39 ` Jeff King
2017-06-26 16:28 ` Jonathan Tan
2017-06-20 1:03 ` [PATCH v4 8/8] sha1_file: refactor has_sha1_file_with_flags Jonathan Tan
2017-06-21 18:18 ` [PATCH v4 0/8] Improvements to sha1_file Junio C Hamano
2017-06-24 12:51 ` Jeff King
2017-06-22 0:40 ` [PATCH v5 " Jonathan Tan
2017-06-22 0:40 ` [PATCH v5 1/8] sha1_file: teach packed_object_info about typename Jonathan Tan
2017-06-22 0:40 ` [PATCH v5 2/8] sha1_file: rename LOOKUP_UNKNOWN_OBJECT Jonathan Tan
2017-06-22 0:40 ` [PATCH v5 3/8] sha1_file: rename LOOKUP_REPLACE_OBJECT Jonathan Tan
2017-06-22 0:40 ` [PATCH v5 4/8] sha1_file: move delta base cache code up Jonathan Tan
2017-06-22 0:40 ` [PATCH v5 5/8] sha1_file: refactor read_object Jonathan Tan
2017-06-22 0:40 ` [PATCH v5 6/8] sha1_file: improve sha1_object_info_extended Jonathan Tan
2017-06-22 0:40 ` [PATCH v5 7/8] sha1_file: do not access pack if unneeded Jonathan Tan
2017-06-22 0:40 ` [PATCH v5 8/8] sha1_file: refactor has_sha1_file_with_flags Jonathan Tan
2017-07-18 10:30 ` Christian Couder
2017-07-18 16:39 ` Jonathan Tan
2017-07-19 12:52 ` Johannes Schindelin
2017-07-19 17:12 ` [PATCH] sha1_file: use access(), not lstat(), if possible Jonathan Tan
2017-07-20 21:48 ` Junio C Hamano
2017-07-22 11:16 ` Johannes Schindelin
2017-07-22 16:15 ` Junio C Hamano
2017-07-25 10:19 ` Johannes Schindelin
2017-06-22 1:40 ` [PATCH v5 0/8] Improvements to sha1_file Junio C Hamano
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=xmqqinjpqm96.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jonathantanmy@google$(echo .)com \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox