Hi Ram, >> Note that there isn't that much difference between being in 'pu' and being >> in the mailing list archive. Depending on how further discussions go, the >> series can be replaced with an improvement or even can be dropped as a >> whole. > > It's an indicator of progress, if not anything else. The project is > already pretty mature imho- after squashing in a few bugfixes, it > should be ready for `next`. I have a feeling that these patches will need a bit more love before they are ready for 'next'. The persistence component is the least mature of the lot. I'd really like some feedback on making the persistence robust and simple. Now that persistence is append-only, the file based representation no longer need be identical to the in-memory representation. I've tried several times to simplify the buffer_read_line() method in line_buffer.h Every time I've ended up with slightly different behaviour. Someone well versed in I/O might be able to greatly simplify it. It may well be reduced to a simple wrapper around strbuf methods. I'm still toying in my head about how to simplify the data structure used to represent the trees. Conceptually, it is a multiway tree with the constraint that the labels of siblings share a common prefix at the parent. It is implemented as a ternary tree with left and right links to siblings in the multiway tree and a middle link to the 'root' child in the multiway tree, from which all children are reachable via left/right links. As the code stands, the middle link is indirected via a 'directory' node. I'd like to remove this redundancy and make the design of the structure clearer. There is scope for a massive rename of methods, arguments and variables so that the code is easier to read. -- David Barr. -- 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