Re: Calculating tree nodes
- From
Andreas Ericsson <ae@op5.se>
- Date
- Sep 4, 2007, 15:14 UTC
- Message-ID
- <46DD7660.2030109@op5.se>
- In-Reply-To
- <9e4733910709040731s2695ab14kb9750923fcac007@mail.gmail.com>
Jon Smirl wrote:
Show 16 quoted lines
> On 9/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: >> Hi, >> >> On Tue, 4 Sep 2007, Jon Smirl wrote: >> >>> In my scheme the path info is moved into the file object nodes and the >>> SHA list is in the commit node. >> And how should this "SHA list" be any different from a single tree object, >> except that you now merge it with the commit object? >> >> Really, go back to the mail Martin mentioned. Having all objects in one >> list kills performance. > > You are ignoring the fact the in this scheme temp indexes can be > created as needed. These temp indexes could look just like tree nodes. >
What's the cost associated with creating such an index? What are the estimated savings in size? What other performance penalties will git take due to this?
While I'm certainly interested in improving git (well, discussing its improvements anyway - I write too shabby code to participate fully), I fail to see how this scheme of storing things could help doing that, seeing as it's already the fastest SCM out there and does an insanely good job at storing large repositories packed up tight.
What you're proposing would effectively shave off ~4kb or so of stored data and save a *possible* disk access (note that there will most likely be none, as most users pack large repos, and for small ones it shouldn't matter much either way). The way you propose to do so involves fundamental and backwards-incompatible alterations to the very core of the git plumbing.
Yet you haven't shown a single estimate of how much diskspace would be saved, or what other gains are to be had, let alone any code to implement even a prototype of this new storage scheme.
Note that I'm currently in a state of mind where I'm feeling inclined to whoop and cheer at every small suggestion that sounds even the slightest bit of fun. No, I'm not doing drugs, but I just met the possible love of my life, got a big fat raise and my stocks just went ballistic. Someone less fortunate than I am right now is probably too bored to even argue against it.
> I'm saying that it may be a mistake to be recording the indexes (aka > file names) as part of the commit when they really aren't.
But they are, since they're part of the snapshot.
> The > essential part of the commit is the SHA1 list. The path names belong > to the file objects and should be stored there. >
Sorry, but it'll take code and benchmarks to convince me this is a good idea. Not that it matters much what I think, but I've got an inkling Junio will need the same before he's swayed to your point of view.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231