From: Junio C Hamano <gitster@pobox•com>
To: Jonathan Tan <jonathantanmy@google•com>
Cc: git@vger•kernel.org, peff@peff•net
Subject: Re: [PATCH v2 3/4] sha1_file: consolidate storage-agnostic object fns
Date: Thu, 15 Jun 2017 10:50:46 -0700 [thread overview]
Message-ID: <xmqq7f0d2l8p.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <33a75a60b1d4298ec0af21c0df19e12bb0e43e2d.1497387714.git.jonathantanmy@google.com> (Jonathan Tan's message of "Tue, 13 Jun 2017 14:05:59 -0700")
Jonathan Tan <jonathantanmy@google•com> writes:
> Looking at the 3 primary functions (sha1_object_info_extended,
> read_object, has_sha1_file_with_flags), they independently implement
> mechanisms such as object replacement, retrying the packed store after
> failing to find the object in the packed store then the loose store, and
> being able to mark a packed object as bad and then retrying the whole
> process. Consolidating these mechanisms would be a great help to
> maintainability.
>
> Therefore, consolidate all 3 functions by extending
> sha1_object_info_extended() to support the functionality needed by all 3
> functions, and then modifying the other 2 to use
> sha1_object_info_extended().
This is a rather "ugly" looking patch ;-) but I followed what
has_sha1_file_with_flags() and read_object() do before and after
this change, and I think this patch is a no-op wrt their behaviour
(which is a good thing).
But I have a very mixed feelings on one aspect of the resulting
sha1_object_info_extended().
> int sha1_object_info_extended(const unsigned char *sha1, struct object_info *oi, unsigned flags)
> {
> ...
> if (!find_pack_entry(real, &e)) {
> /* Most likely it's a loose object. */
> - if (!sha1_loose_object_info(real, oi, flags)) {
> + if (oi && !sha1_loose_object_info(real, oi, flags)) {
> oi->whence = OI_LOOSE;
> return 0;
> }
> + if (!oi && has_loose_object(real))
> + return 0;
This conversion is not incorrect per-se.
We can see that has_sha1_file_with_flags() after this patch still
calls has_loose_object(). But it bothers me that there is no hint
to future developers to warn that a rewrite of the above like this
is incorrect:
if (!find_pack_entry(read, &e)) {
/* Most likely it's a loose object. */
+ struct object_info dummy_oi;
+ if (!oi) {
+ memset(&dummy_oi, 0, sizeof(dummy_oi);
+ oi = &dummy_oi;
+ }
- if (oi && !sha1_loose_object_info(real, oi, flags)) {
+ if (!sha1_loose_object_info(real, oi, flags)) {
oi->whence = OI_LOOSE;
return 0;
}
- if (!oi && has_loose_object(real))
- return 0;
It used to be very easy to see that has_sha1_file_with_flags() will
call has_loose_object() when it does not find the object in a pack,
which will result in the loose object file freshened. In the new
code, it is very subtle to see that---it will happen when the caller
passes oi == NULL, and has_sha1_file_with_flags() is such a caller,
but it is unclear if there are other callers of this "consolidated"
sha1_object_info_extended() that passes oi == NULL, and if they do
also want to freshen the loose object file when they do so.
> @@ -3480,18 +3491,12 @@ int has_sha1_pack(const unsigned char *sha1)
>
> int has_sha1_file_with_flags(const unsigned char *sha1, int flags)
> {
> - struct pack_entry e;
> + int f = OBJECT_INFO_SKIP_CACHED |
> + ((flags & HAS_SHA1_QUICK) ? OBJECT_INFO_QUICK : 0);
>
> if (!startup_info->have_repository)
> return 0;
> - if (find_pack_entry(sha1, &e))
> - return 1;
> - if (has_loose_object(sha1))
> - return 1;
> - if (flags & HAS_SHA1_QUICK)
> - return 0;
> - reprepare_packed_git();
> - return find_pack_entry(sha1, &e);
> + return !sha1_object_info_extended(sha1, NULL, f);
> }
I would have preferred to see the new variable not to be called 'f',
as that makes it unclear what it is (is that a callback function
pointer?). In this case, uyou are forcing the flag bits passed
down, so perhaps you can reuse the same variable?
If you allocated a separate variable because
has_sha1_file_with_flags() and sha1_object_info_extended() take flag
bits from two separate vocabularies, that is a valid reasoning, but
if that is the case, then I would have named 'f' to reflect that
fact that this is different from parameter 'flag' that is defined in
the has_sha1_file_with_flags() world, but a different thing that is
defined in sha1_object_info_extended() world, e.g. "soie_flag" or
something like that.
Thanks.
next prev parent reply other threads:[~2017-06-15 17:50 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 [this message]
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
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=xmqq7f0d2l8p.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