> Assuming SHA1 never collides (collisions rule out any form of storage,
> so we might as well hope it never happens), that leaves us with this:
>
> Each root tree can only ever belong to a single commit, unless you
> intentionally force git to make completely empty commits. git
> won't complain about this, so long as you don't make two in the
> same second, because it relies more heavily on the DAG than on
> developer sanity.
>
> Each root tree can point to multiple sub-trees. The sub-trees can be
> linked to any number of root-trees.
>
> Blobs can be linked to any number of tree objects, or even multiple
> times to the same tree object. This wouldn't be possible if the
> blob objects had their own pathnames stored inside them, so to speak.
>
> >
> > The file name table is encoded as an index and it has been
> > intermingled with the commit table.
> >
> > Looking at this from a set theory angle brings up the question, do we
> > really have three tables and file names are an independent variable
> > from the blobs, or should file names be an attribute of the blob?
> >
>
> File names are not independant variables. They belong inside the
> table created for them, which is the tree objects.
>
> > How this gets structured in the db is an independent question about
> > how renames get detected on a commit. The current scheme for detecting
> > renames by comparing diffs is working fine. The question is, once we
> > detect a rename how should it be stored?
> >
>
> Do you realize that you're contradicting yourself in two upon each
> other following sentences here?
>
> Detecting renames after the fashion works fine. Not storing them
> is part of the "detect them by comparing diffs".
>
> > Ignoring the performance impacts and looking at the problem from the
> > set theory view point, should:
> > the pathnames be in their own table with a row for each alias
> > the pathnames be stored as an attribute of the blob
> >
> > Both of these are the same information, we're just looking at how
> > things are normalized.
> >
>
> Except that
>
> git init
> echo foo > a
> cp -a a b
> git add .
> git commit -m testing
> git count-objects
>
> yields 3 objects at the moment; A commit-object, a tree object and *one*
> blob object. With your scheme the 2 blob objects would differ, and there
> would be 4 of them. If you propose to ignore the path-name you have
> effectively broken support for having two identical files with different
> names in the same directory.
>
> Now, can you please tell me what gains you're hoping to see with this
> new layout of yours?
>
> --
> Andreas Ericsson
andreas.ericsson@op5.se
> OP5 AB
www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
