git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Petr Baudis <pasky@ucw.cz>, Zack Brown <zbrown@tumblerings.org>,
	git@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: speeding up cg-log -u
Date: Mon, 16 May 2005 01:13:21 -0700	[thread overview]
Message-ID: <7voebboafy.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.21.0505151158300.30848-100000@iabervon.org> (Daniel Barkalow's message of "Sun, 15 May 2005 12:09:55 -0400 (EDT)")

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

DB> Existance is the primary thing, and everything else was added as
DB> needed. (Pure connectivity is a bit special, because it's a property of
DB> generic objects so that fsck-cache doesn't need to know about particular
DB> types of objects unless there are particular things to check about them)

DB> If you need more fields, let me know, and I'll figure out how to include
DB> them.

Could you take a look at the latest round of the patch and see
what I did there makes sense?

    From: Junio C Hamano <junkio@cox.net>
    Date: Sun, 15 May 2005 14:18:36 -0700
    Message-ID: <7vy8agqjbn.fsf@assigned-by-dhcp.cox.net>
    Subject: [PATCH 1/4] Add --author and --committer match
             to git-rev-list and git-rev-tree.

Another thing I wanted to ask you about was lifetime rules.
When we "lookup" these objects (and then "parse" them, which
causes more memory to be used), who is responsible for freeing
them?  When my program thinks it is done with a commit, is it
allowed to free it?  Or does the lookup machinery own all of the
objects that have ever been looked up, and the program should
not worry about freeing them to begin with?


  reply	other threads:[~2005-05-16  8:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-14  6:19 speeding up cg-log -u Zack Brown
2005-05-14  8:13 ` Junio C Hamano
2005-05-14  9:50 ` [PATCH] Add --author match to git-rev-list and git-rev-tree Junio C Hamano
2005-05-14 15:06   ` Zack Brown
2005-05-14 15:52     ` Petr Baudis
2005-05-14 16:02       ` Zack Brown
2005-05-14 10:39 ` speeding up cg-log -u Petr Baudis
2005-05-14 11:14   ` Petr Baudis
2005-05-14 11:17   ` Junio C Hamano
2005-05-14 14:23     ` Zack Brown
2005-05-14 14:40       ` Petr Baudis
2005-05-15 16:09     ` Daniel Barkalow
2005-05-16  8:13       ` Junio C Hamano [this message]
2005-05-16 15:38         ` 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=7voebboafy.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 \
    --cc=zbrown@tumblerings.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;
as well as URLs for NNTP newsgroup(s).