Re: [RFC PATCH 2/4] sha1_file: extract type and size from object_info

On Mon, Jun 12, 2017 at 12:52:54PM -0700, Jonathan Tan wrote: > > I like the idea of consolidating the logic. But I can't help but feel > > that pulling these fields out of object_info is a step backwards. The > > point of that struct is to let the caller specify which aspects of the > > object

Re: [RFC PATCH 2/4] sha1_file: extract type and size from object_info

On Sat, 10 Jun 2017 03:01:33 -0400 Jeff King wrote: > On Fri, Jun 09, 2017 at 12:23:24PM -0700, Jonathan Tan wrote: > > > Looking at the 3 primary functions (sha1_object_info_extended, > > read_object, has_sha1_file_with_flags), they independently implement > > mechanisms such as

Re: [RFC PATCH 2/4] sha1_file: extract type and size from object_info

On Fri, Jun 09, 2017 at 12:23:24PM -0700, Jonathan Tan wrote: > 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

[RFC PATCH 2/4] sha1_file: extract type and size from object_info

This is patch 1 of 2 to consolidate all storage-agnostic object information functions. In sha1_file.c, there are a few functions that provide information on an object regardless of its storage (cached, loose, or packed). Looking through all non-static functions in sha1_file.c that take in an