git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v7 1/4] sha1_file.c: support reading from a loose object of unknown type

From
karthik nayak <karthik.188@gmail.com>
Date
Apr 7, 2015, 10:34 UTC
Message-ID
<5523B2A7.6060604@gmail.com>
In-Reply-To
<xmqqbnj2e4ah.fsf@gitster.dls.corp.google.com>
On 04/06/2015 01:27 AM, Junio C Hamano wrote:
Show 77 quoted lines
> karthik nayak <karthik.188@gmail.com> writes:
>
> > On 04/05/2015 01:16 PM, Junio C Hamano wrote:
> >
> >> If it semantically does not make sense to ask for the typename
> >> without asking for the type code, then we can and should make that
> >> as a new calling convention _all_ callers must follow.
> >>
> >> In other words, I think it is better to have
> >>
> >>     if (oi->typename && !oi->typep)
> >>         die("BUG");
> >>
> >> somewhere near the beginning of the callchain that takes oi; that
> >> will ensure all callers understand the rule.
> >
> > Yes! this is a better approach as it will enforce that typep must be
> > set when typename is set.
>
> Not so fast ;-)
>
> The key phrase in what I wrote above is "If it does not make sense",
> and I am not yet convinced if that is the case or not.  If we are to
> change the calling convention for the callers, the reason why it
> does not make sense to ask only for typename but not typep must be
> explained in the log message.
>
> And if it turns out that the answer to that question is "it is valid
> to ask only for typename", then it would be wrong to force everybody
> who wants to learn the stringified typename to supply typep.  And in
> such a case it might be better to do something like this instead (on
> top of your patch I am responding to):
>
>   sha1_file.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index f4055dd..26fbb7c 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2639,6 +2639,7 @@ int sha1_object_info_extended(const unsigned char *sha1, struct object_info *oi,
>       struct cached_object *co;
>       struct pack_entry e;
>       int rtype;
> +    enum object_type real_type;
>       const unsigned char *real = lookup_replace_object_extended(sha1, flags);
>
>       co = find_cached_object(real);
> @@ -2670,9 +2671,18 @@ int sha1_object_info_extended(const unsigned char *sha1, struct object_info *oi,
>               return -1;
>       }
>
> +    /*
> +     * packed_object_info() does not follow the delta chain to
> +     * find out the real type, unless it is given oi->typep.
> +     */
> +    if (oi->typename && !oi->typep)
> +        oi->typep = &real_type;
> +
>       rtype = packed_object_info(e.p, e.offset, oi);
>       if (rtype < 0) {
>           mark_bad_packed_object(e.p, real);
> +        if (oi->typep == &real_type)
> +            oi->typep = NULL;
>           return sha1_object_info_extended(real, oi, 0);
>       } else if (in_delta_base_cache(e.p, e.offset)) {
>           oi->whence = OI_DBCACHED;
> @@ -2686,6 +2696,8 @@ int sha1_object_info_extended(const unsigned char *sha1, struct object_info *oi,
>       if (oi->typename)
>           strbuf_addstr(oi->typename, typename(*oi->typep));
>
> +    if (oi->typep == &real_type)
> +        oi->typep = NULL;
>       return 0;
>   }
>
>

Haha, If there is anything I love about code revisions its how you are subjected to so many different ways of thinking. I didn't think of what you said.

We could do this and support typename without typep being used. This could probably even eliminate the typep used by cat-file while getting the type of an object.

Will go through this again.
Thanks a lot.
Previous: Junio C HamanoNext: Karthik Nayak
Message 8 of 19 in “cat-file: teach cat-file a '--literally' option”
  1. 0/4 cat-file: teach cat-file a '--literally' optionkarthik nayak, Apr 4, 2015
  2. 1/4 sha1_file.c: support reading from a loose object of unknown typeKarthik Nayak, Apr 4, 2015
  3. Junio C HamanoApr 4, 2015
  4. karthik nayakApr 4, 2015
  5. Junio C HamanoApr 5, 2015
  6. karthik nayakApr 5, 2015
  7. Junio C HamanoApr 5, 2015
  8. karthik nayakApr 7, 2015
  9. 1/4 sha1_file.c: support reading from a loose object of unknown typeKarthik Nayak, Apr 5, 2015
  10. Eric SunshineApr 7, 2015
  11. 2/4 cat-file: teach cat-file a '--literally' optionKarthik Nayak, Apr 4, 2015
  12. Eric SunshineApr 7, 2015
  13. 3/4 cat-file: add documentation for '--literally' option.Karthik Nayak, Apr 4, 2015
  14. Eric SunshineApr 7, 2015
  15. 4/4 t1006: add tests for git cat-file --literallyKarthik Nayak, Apr 4, 2015
  16. Eric SunshineApr 7, 2015
  17. karthik nayakApr 8, 2015
  18. Eric SunshineApr 8, 2015
  19. Karthik NayakApr 9, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.