Re: Git's database structure

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 4, 2007, 18:06 UTC
Message-ID: <7v1wdenw4n.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <9e4733910709041044r71264346n341d178565dd0521@mail.gmail.com>

"Jon Smirl" <jonsmirl@gmail.com> writes:

Show 22 quoted lines

> On 9/4/07, Junio C Hamano <gitster@pobox.com> wrote:
>> "Jon Smirl" <jonsmirl@gmail.com> writes:
>>
>> > Another way of looking at the problem,
>> >
>> > Let's build a full-text index for git. You put a string into the index
>> > and it returns the SHAs of all the file nodes that contain the string.
>> > How do I recover the path names of these SHAs?
>>
>> That question does not make much sense without specifying "which
>> commit's path you are talking about".
>>
>> If you want to encode such "contextual information" in addition
>> to "contents", you could do so, but you essentially need to
>> record commit + pathname + mode bits + contents as "blob" and
>> hash that to come up with a name.
>
> I left the details out of the full-text example to make it more
> obvious that we can't recover the path names.
>
> Doing this type of analysis may point out that even more fields are
> missing from the blob table such as commit id.

Quite the contrary. You just illustrated why it is wrong to put anything but contents in the blob.

The specialized indexing is a different issue. If you want to have a full text index to answer "what paths in which commits had this string?", then your database table would have columns such as commit (sha-1), path (string) as values, indexed with the search string.

Now the current set of "git" operation does not need to answer that query, so we do not build nor maintain such an index that nobody uses. But your application may benefit from such an index, and as others said, nobody prevents you from building one.