Re: Git's database structure

[Junio C Hamano <gitster@pobox.com>]

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

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