ref: ab174c473618dd3743881cf44e02c2db4d1ecd5f
dir: /TODO/
Missing operations that git.sr.ht needs ======================================= * Repository init * Clone/fetch (but that's handled by the CLI) * Resolving revisions * Better diffing; patch generation * Log and revision walking, optionally filtered by path * Config writing Missing operations that tangled needs ===================================== * Repository init * Clone/fetch (but that's handled by the CLI) * Resolving revisions * Better diffing; patch generation * Submodule config (but we should make the CLI handle these) * Potentially, convenience APIs for branch/tag refs * Log and revision walking, optionally filtered by path Unstructured ones ================= * Receive-pack hook shape redesign; separate post-ref and post-ingest hook types. * Completely redo error handling. * Better status reporting, filling in more things in report-status-v2. * Maybe the Progress/Error writers should return error on creation instead of automatically discarding content? * Actually making signed-push work reasonably * Investigate fsck issues with receive-pack * Improve performance of delta resolution * Okay, I think this is still a real design issue, just at a different layer now. receive-pack and the object stores are better than they were when pack ingest still wanted raw roots, and we now have coordinated quarantines and a dual store to represent the normal mix. However, that probably isn't the end state either. In the usual repository layout, loose and packed objects are really two parts of one files object storage, and dual may just be an intermediate abstraction until files-backed storage gets a more integrated API, including in particular, ingress/quarantine. We should preserve the current separation for now, because it keeps the boundaries there, and is much simpler than trying to prematurely fuse everything together, but if receive-pack and hooks keep growing around dual then that is probably a sign that the underlying files object storage wants a interface of its own. * Digital signature API * Revision-ish entry points like if you get main or v1.0 we should try to resolve that probably * Needs much better diff API * revwalk/log