Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
	git@vger.kernel.org, Petr Baudis <pasky@ucw.cz>
Subject: Re: [PATCH] Make object contents optionally available
Date: Tue, 17 May 2005 12:32:37 -0700	[thread overview]
Message-ID: <7vbr79fy22.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: Pine.LNX.4.21.0505171325150.30848-100000@iabervon.org

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

DB> It wouldn't make any types special; the caller can just control each type
DB> individually, so that code that only cares about commits could get commits
DB> unpacked, but not get trees unpacked even if it has them parsed.

That is exactly the behaviour I am questioning about.  You are
giving the caller the ability to discriminate objects based on
their _type_ (which is fine and better than not having that
control at all).  Why can't the caller discriminate objects
based on their, say, size for example [*1*]?  That's what I
meant to say by "types are special" but I phrased it so badly.
 
And the callback would solve that naturally.  Or you can
additionally give the callback the result of the parse_xxx(),
which would be even more useful.  The callback can then throw
commit raw-data away based on the date, for example.

[Footnote]

*1* So this hypothethical program uses fast cached raw data for
small things but is willing to pay penalty for big things if it
later finds those big things turn out to be needed.


  reply	other threads:[~2005-05-17 19:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-17  4:56 [PATCH] Make object contents optionally available Daniel Barkalow
2005-05-17 15:29 ` Linus Torvalds
2005-05-17 15:52   ` Daniel Barkalow
2005-05-17 17:12     ` Junio C Hamano
2005-05-17 17:55       ` Daniel Barkalow
2005-05-17 19:32         ` Junio C Hamano [this message]
2005-05-17 19:59           ` Daniel Barkalow

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=7vbr79fy22.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=pasky@ucw.cz \
    --cc=torvalds@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox