From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Kastrup <dak@gnu.org>
Cc: Uwe Kleine-K?nig <ukleinek@informatik.uni-freiburg.de>,
git@vger.kernel.org
Subject: Re: Can I have this, pretty please?
Date: Sun, 12 Aug 2007 13:21:38 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0708121315310.30176@woody.linux-foundation.org> (raw)
In-Reply-To: <85k5s0msei.fsf@lola.goethe.zz>
On Sun, 12 Aug 2007, David Kastrup wrote:
> >
> > rev-list doesn't try to draw a line from each commit to its parents.
>
> Well, that's what --topo-order is somewhat about, but it might
> actually not do much together with --all.
No, --topo-order works with --all too. In fact, to some degree, it's
*especially* useful with --all, since having multiple tips makes the whole
topological sort all the more interesting, and also usually makes the end
result more interesting (ie it's often much more interestign to visualize
two or more branches together, just to see the *relationships* between the
branches, and see what is shared.
And yes, it keeps track of every single commit, and computes the
relationships between them. So it does indeed "draw the line", except it
can do so in a rather dense and optimized set of data structures.
(That's one reason I love coding in C: it may be more effort, but you can
tune your data structures in ways you seldom can in higher-level
languages, and git-rev-list and the object representation is some of the
most tuned code in git).
> 20 bytes of payload for a commit number. Make a usable hashing data
> structure for it, adds perhaps another 20 bytes. Links to all parents
> are 4 bytes each. All in all, we won't need more than 64 bytes per
> commit.
Yeah, that's the rough ballpark (except for 64-bit architectures, the
links are all 8 bytes, but we're pretty careful). See "object.h" for most
of the details.
Linus
next prev parent reply other threads:[~2007-08-12 20:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-12 13:23 Can I have this, pretty please? David Kastrup
2007-08-12 14:21 ` Steven Grimm
2007-08-12 16:40 ` David Kastrup
2007-08-12 18:38 ` Linus Torvalds
2007-08-12 18:48 ` Linus Torvalds
2007-08-12 19:28 ` Jon Smirl
2007-08-12 19:45 ` Linus Torvalds
2007-08-12 19:48 ` David Kastrup
2007-08-12 19:29 ` David Kastrup
2007-08-12 19:51 ` Uwe Kleine-König
2007-08-12 20:04 ` David Kastrup
2007-08-12 20:21 ` Linus Torvalds [this message]
2007-08-12 19:53 ` Linus Torvalds
2007-08-12 20:10 ` David Kastrup
2007-08-13 0:22 ` Paul Mackerras
2007-08-13 5:49 ` David Kastrup
2007-08-12 19:10 ` David Kastrup
2007-08-12 19:24 ` Linus Torvalds
2007-08-12 19:46 ` David Kastrup
2007-08-12 19:59 ` Linus Torvalds
2007-08-12 20:30 ` David Kastrup
2007-08-12 20:58 ` Govind Salinas
2007-08-12 21:35 ` David Kastrup
2007-08-12 22:17 ` Martin Langhoff
2007-08-12 22:54 ` David Kastrup
2007-08-12 20:02 ` Jeff King
2007-08-12 20:09 ` Jeff King
2007-08-12 21:51 ` David Kastrup
2007-08-12 23:10 ` Jeff King
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=alpine.LFD.0.999.0708121315310.30176@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=ukleinek@informatik.uni-freiburg.de \
/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).