All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: karthik nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, sunshine@sunshineco.com
Subject: Re: [PATCH v7 1/4] sha1_file.c: support reading from a loose object of unknown type
Date: Sun, 05 Apr 2015 12:57:58 -0700	[thread overview]
Message-ID: <xmqqbnj2e4ah.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5520E9D2.4010603@gmail.com> (karthik nayak's message of "Sun, 05 Apr 2015 13:22:50 +0530")

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;
 }
 

  reply	other threads:[~2015-04-05 19:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-04  5:41 [PATCH v7 0/4] cat-file: teach cat-file a '--literally' option karthik nayak
2015-04-04  5:42 ` [PATCH v7 1/4] sha1_file.c: support reading from a loose object of unknown type Karthik Nayak
2015-04-04 19:34   ` Junio C Hamano
2015-04-04 19:53     ` karthik nayak
2015-04-05  7:46       ` Junio C Hamano
2015-04-05  7:52         ` karthik nayak
2015-04-05 19:57           ` Junio C Hamano [this message]
2015-04-07 10:34             ` karthik nayak
2015-04-05 18:28   ` Karthik Nayak
2015-04-07 20:46     ` Eric Sunshine
2015-04-04  5:44 ` [PATCH v7 2/4] cat-file: teach cat-file a '--literally' option Karthik Nayak
2015-04-07 20:49   ` Eric Sunshine
2015-04-04  5:44 ` [PATCH v7 3/4] cat-file: add documentation for " Karthik Nayak
2015-04-07 20:49   ` Eric Sunshine
2015-04-04  5:44 ` [PATCH v7 4/4] t1006: add tests for git cat-file --literally Karthik Nayak
2015-04-07 20:49   ` Eric Sunshine
2015-04-08 17:42     ` karthik nayak
2015-04-08 20:34       ` Eric Sunshine
2015-04-09  3:24         ` Karthik Nayak

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=xmqqbnj2e4ah.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.