Re: Git's database structure

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 4, 2007, 17:21 UTC
Message-ID: <7vy7fmny6y.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <46DD7FE4.1060908@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 5 quoted lines

> 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.

Show 6 quoted lines

> 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.