On 9/4/07, Junio C Hamano <gitster@pobox.com> wrote:
quoted text
> "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.

The current data store design is not very flexible. Databases solved
the flexibility problem long ago. I'm just wondering if we should
steal some good ideas out of the database world and apply them to git.
Ten years from now we may have 100GB git databases and really wish we
had more flexible ways of querying them.

The reason databases don't encode the fields into the index is that
you can only have a single index on the table if you do that.
Databases do sometimes duplicate the field in both the index and the
table. Databases also have the property that indexes are just a cache
and can be dropped at any time.

-- 
Jon Smirl
jonsmirl@gmail.com
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html