Jon Smirl wrote:
On 9/4/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
