Re: Git's database structure

"Jon Smirl" [off-list ref] writes:

On 9/4/07, Junio C Hamano [off-list ref] wrote:

quoted

"Jon Smirl" [off-list ref] writes:

quoted

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.