josh _(just one simple history)_

[Byron]

• lookup references by name
• http with authentication
• init bare repository
• open repository directly, without discovery
• build a tree in memory (needs ability to obtain hashes, maybe with `sink()
  • make it nice to use
• hash objects into memory
• tree walking
• walk commit graph
• list references by glob
• rev parsing (rev-spec)
• find commits/trees by oid
• a whole lot of commands are delegated to git CLI, that's fine

https://github.com/esrlabs/josh

Related PRs

• parse revision specifications #428

[vlad-ivanov-name]

Hello @Byron,

I'm one of contributors of josh-project/josh, and I wanted to comment a bit on the list of features you posted above.

Currently Josh uses two git implementations underneath - git and libgit2. Git is responsible for:

• upstream interaction, such as fetch or push
• repo init
• serving repositories to the user

libgit2 is used to:

• traverse commit graph
• create new histories
• perform other operations involving actual repo objects

While it would certainly be an improvement to use gitoxide as a drop-in git replacement and git-repository as a library, it would be much better if we could drop the whole concept of running a git subprocess completely, and only use git-repository as a library. So current design choices are not as much a result of choosing the best architecture, but are rather dictated by the available software libraries.

In a long-term perspective, here are some of the things we would need to implement in Josh to overcome existing git limitations:

• make josh serve repositories itself, instead of relying on git-upload-pack / git-receive-pack / git-http-backend (issue Server-side of fetch/pull #307)
• abstract away from storing object files and other data on the filesystem; use object storage (with cache) instead

So overall, we want to move away from running git CLI.

Btw -- if you're interested in more details on how Josh works internally, I dropped you a keybase message, the authors of the project will be more than happy to discuss it with you.

[Byron]

Thanks for chiming in. It will probably be a while until gitoxide can serve all your needs, but if it helps, I will push hard towards a server implementation to be ready by the end of 2023. Your participation in the process should help to make it general enough to provide building blocks for josh as well.

About abstracting away the actual object storage, that should be possible as gitoxide already has a couple of traits to work with around writing objects and retrieving them, but at the moment one implementation of these is hard-coded. I don't have any plans yet to change this, but thanks to the layering of crates it should always be possible to re-use lower-level bits and pieces.

I replied to the keybase message so we can have a chat about that.