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