Thanks, Junio. A reply to your comment on patch 7:
> ... this "if" statement feels like a maintenance nightmare. The
> intent of the guard, I think, is "when the call wants absolutely
> nothing but whence", but the implementation of the guard will not
> stay true to the intent whenever somebody adds a new field to oi.
>
> I wonder if it makes more sense to have a new field "whence_only",
> which is set only by such a specialized caller, which this guard
> checks (and no other fields).
After some more thought, I think I came up with a better solution -
allow sha1_object_info_extended() to take a NULL struct object_info
pointer, and immediately assign it (if NULL) a blank struct, but use the
NULL-ness as an indication that we can skip accessing the packfile. The
last patch actually doesn't even need the "whence", so we can do this.
Changes from v4:
- patch 2
- Updated commit message to explain why
OBJECT_INFO_ALLOW_UNKNOWN_TYPE is defined to be 2, not 1.
- patch 3
- Made all invocations of sha1_object_info_extended() compare "< 0".
- patch 5
- Made all invocations of sha1_object_info_extended() compare "< 0".
- patch 7
- Rewrote patch to make sha1_object_info_extended() accept NULL
struct object_info pointer.
- patch 8
- Made has_sha1_file_with_flags send NULL instead of blank struct
object_info.
Jonathan Tan (8):
sha1_file: teach packed_object_info about typename
sha1_file: rename LOOKUP_UNKNOWN_OBJECT
sha1_file: rename LOOKUP_REPLACE_OBJECT
sha1_file: move delta base cache code up
sha1_file: refactor read_object
sha1_file: improve sha1_object_info_extended
sha1_file: do not access pack if unneeded
sha1_file: refactor has_sha1_file_with_flags
builtin/cat-file.c | 7 +-
builtin/fetch.c | 10 +-
builtin/index-pack.c | 3 +-
cache.h | 36 +++--
sha1_file.c | 385 ++++++++++++++++++++++++++-------------------------
5 files changed, 224 insertions(+), 217 deletions(-)
--
2.13.1.611.g7e3b11ae1-goog
