Re: What's cooking in git.git (Apr 2010, #05; Wed, 14)

[Nick Edelen <sirnot@gmail.com>]

>* ne/rev-cache (2010-04-05) 7 commits
> . graft awareness
> . object name support
> . integration into revision walker
> . administrative api and tools
> . support for non-commit objects
> . basic api and porcelain
> . man page and technical docs
>
>For some reason this was extremely hard to read, partly because it had too
>many distracting style violations and too many long lines.

What sort of style violations?  I tried to be quite careful about
that, but evidently I wasn't successful :-/

I'm sorry about the long lines -- all but a handful should fit on a
standard xga resolution screen, which I figured was something of a
minimum for screen width now?

>This duplicates quite a similar traversal logic and hijacks the control
>from sideways in a very core part of the revision walker, making it a
>maintenance nightmare.

I realize that might be a problem, but it seems to be sorta
unavoidable.  The goal is to allow highly-efficient retrieval of
metadata in revision walking, and in order to figure out what metadata
is required (preferably with minimum redundancy), at least some
portion of the revision walker is going to be duplicated.

It was intended to something of an alternative walker in its own
right, which could supplement standard revision traversal by passing
control back and forth based on what was available in the caches.  In
this way the API was to additionally provide a possible doorway for
third-parties to have ready, fast access to the commit tree, without
trudging through individual object files.

I don't think maintenance would really be that nightmarish.  First,
rev-cache is quite distinct from git's core, and is only (tentatively)
integrated by a few lines of code.  It keeps its own cache-slice
format independent from git's objects, and is transparent to almost
every git function (so, e.g., completely changing git's daemon would
have no influence on the rev-cache's effectiveness, as long as
revision walking is not significantly altered).

Second, the key logic is does duplicate (= mainly the interestingness)
is so fundamental that any large change would require a huge rewrite
of most of gits internals anyway, let alone rev-cache.  Other
duplication (e.g. max/min dates) is no harder to alter than in
revision.c; indeed, most of the time it'd be simpler.  Additionally,
for anything more complicated than simple traversal (e.g. pruning)
revision caching is disabled.

Care is taken to make it as unobtrusive as possible: if it can provide
extra help, it will, but as far as git's concerned it dosn't exist.

>After I noticed that it still writes/reads
>structures with bitfields directly on-disk, which I pointed out number of
>times is a no-no during the initial review

Unless I missed something, I had thought I specifically addressed this
issue.  I even went so far as to prevent direct structure writes of
any kind (contrary to the read-cache.c functions, my initial guide for
such strictness), explicitly converting structures to/from char
arrays.

 - Nick