Theodore Tso wrote:
>On Fri, Sep 12, 2008 at 07:47:39AM +0200, Stephen R. van den Berg wrote:
>> It would probably become computationally prohibitive to use it between
>> long lived permanent branches. In that case it would need to be
>> augmented by the sha1 of the originating commit.
>Nope, as Sam suggested in his original message (but which got clipped
>by Linus when he was replying) all you have to do is to have a
>separate local database which ties commits and patch-id's together as
>a cache/index.
True. But repopulating this cache after cloning means that you have to
calculate the patch-id of *every* commit in the repository. It sounds
like something to avoid, but maybe I'm overly concerned, I have only a
vague idea on how computationally intensive this is.
>I know you seem to be resistent to caches, but caches are **good**
>because they are local information, which by definition can be
>implementation-dependent; you can always generate the cache from the
>git repository if for some reason you need to extend it. It also
>means that if it turns out you need to index reationships a different
>way, you can do that without having to make fundamental (incompatible)
>changes in the git object.
I fully agree that caches are good.
And yes I seem to resist the idea to create a cache at every whim, but
that mostly is because I want to avoid that everyone invents their own
mini-database for each and every data access they want to accellerate.
I mean, ideally, any database/index/accellerator structure you'd need
can reuse the SHA1 object database index, or maybe one or two other
semi-standard index types, and git would provide suitable library
functions for all three solutions. And if that would be the case, I'll
gladly throw in an extra cache or index at anytime to speed up the
particular access pattern I'm trying to make useable. But as far as I
can see, those library functions have not materialised yet, so I'm
hesitant to create yet another private database structure just for my
access patterns; and simply pulling in libdb or sqlite without agreement
that those libs are (re)used in a lot of places in git seems a bit
bloat-prone.
>local caches are database indexes. Just because you need an index in
>a particular direction to optimize a query or loopup operation does
>***not*** imply that you need to make a fundamental, globally visible,
>database schema change or git object layout which breaks compatibility
>for everybody.
It's not a certainty that changing the git object layout has to break
compatibility (it should be reasonably possible to add columns to the
schema without breaking anything, to stay with the database paradigm),
but I agree that creating another index can be considered better than
extending the schema.
--
Sincerely,
Stephen R. van den Berg.
"Father's Day: Nine months before Mother's Day."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
