Skip to content

Latest commit

 

History

History
113 lines (85 loc) · 4.68 KB

tasks.md

File metadata and controls

113 lines (85 loc) · 4.68 KB

This file sketches out the tasks required to be able to clone a repository whilst checking out its head ref.

Client side push (client to server)

  • git-odb

    • basic pack generation based on tree-diff or tree-traversal

  • git-protocol

    • ReceivePack logic for V1 and V2
    • async & blocking negotiation of commits

Client fetch/pull (server to client)

  • git-odb

The below is a very early draft - it would be better to study existing implementations first to get a better overview on what (not) to do. This one starts with the fun part to allow writing tests early and experiment with different diff algorithms and potentially their performance.

  • generate a pack from objects received by an iterator producing (see issue)
    • base objects only
    • re-use existing delta objects
    • best-fit delta objects using the similar
    • A mechanism to declare some bases to be 'out of pack' for thin pack support
  • Traversal (as building blocks to feed pack generation)
    • Traverse a commit graph (look around to see what's common, if in doubt walk back the commit graph and see how to deal with branching)
    • Traverse trees
  • Iterator to feed pack generation efficiently
  • git-transport

Certainly needs more research, but roughly…

  • Server side accept()

    • http(s)
    • ssh
    • daemon probaby only used in testing, and we might implement it if it's useful for us as well

  • git-protocol

    • Server side chatter to negotiate a pack for
      • protocol V2
      • protocol V1 (probably not worth it, let's see)

  • gix-serve

Probably more like a toy at first merely for testing operation against various git clients.

  • A server able to answer via
    • http(s)
    • file protocol (or remote invocation via SSH)

Repository Clone

  • git-odb
    • all docs, sans examples
    • Rename pack data/pack index Kind to Version or similar, because that's what it really is.
  • git-object refactor
    • split Id and everything hash related into git-id
    • use git-id inside of git-features, remove cycle
  • git-config
    • Thanks to a generous contribution it's mostly done and well on the way
    • Push it towards 1.0
    • Config type which integrates multiple files into one interface, much like a multi version of File
    • Make gix organize use git-config on single files (the repository configuration)
  • git-ref
    • create ref pointing to ID
      • assure to keep the path towards symbolic refs open, and allow specifying if these should be followed or not
  • git-index
    • Create an index from tree
    • Checkout index to worktree
  • git-repository
    • instance for a valid looking repository
      • support shallow repos/references
    • create-update refs as received from clone/git-receive-pack safely (i.e. with required locking)
    • clone from https remote
  • gix clone
    • try initializing repo on output path - if so, use that to learn about pack location and place new pack there, allow Repo to create refs somehow.
      • probably this is done using the repository itself, which steers the whole process and injects it's own delegates.
    • otherwise create the scaffolding needed for a new repository, probably based on init implementation
  • gixp receive-pack
    • resolve thin pack with Bundle

FSCK an entire repository

  • multi-db (incorporate object lookup for loose objects and packs)
    • singlemulti-threaded
    • objectpack-cache for speedups
    • fs-check - verify all object content of a git repository
      • probably this should be based on indexed pack traversal for maximum decoding speed and not on individual object lookup

gix organize

  • Add journey test to cover case with non-bare repository. Try to only read non-bare git config files and see the journey test fail.

gixp cat

  • A program to cat objects and pretty-print them, similar to git cat-file. Useful to get a feel for 'locate(…)' performance and stress test it a little.
  • Be sure to escape terminal escape codes

Feature Flags

  • configure the small feature set so that the flate2 backend is miniz-oxide instead of zlib-ng, allowing a 'pure' rust build. This might mean that the fast feature contains zlib-ng.

  • Questions