Re: Git's database structure

Andreas Ericsson [off-list ref] writes:

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.

This actually can happen without even using 'ours' strategy.

If two people independently applied the same patch on their
branches and later their results were merged.  And "the same
second" requirement is not even there and not interesting.
There are other things like developer identity, log message, and
their ancestry that would make the resulting commit object
distinct.

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.

More importantly, in git, filenames and modes are not considered
part of "contents", which git tracks.  Although it is an
entirely possible and valid alternate design to move that as
part of "blob" to build a system that is different from git,
which Jon seems to be aiming at, the benefit of such a design is
unclear to me, both from theoretical point of view (now blobs
are not about pure contents anymore) nor performance point of
view (Linus's done flat tree object in an early stage of git,
and it was not nice) as other people explained.