|
| 1 | +# Overview |
| 2 | + |
| 3 | +The motivation is to provide a `git`-like command-line interface (CLI) to the |
| 4 | +[JupyterLite terminal](https://github.com/jupyterlite/terminal) but allow most of the development |
| 5 | +work to occur outside of a WebAssembly toolchain for ease. |
| 6 | + |
| 7 | +[libgit2](https://libgit2.org/) is a portable pure C implementation of `git` core functionality to |
| 8 | +allow library access rather than a CLI. There are many different programming language wrappers for |
| 9 | +it. It does include some CLI functionality in the form of examples, but these are not of core |
| 10 | +interest to most maintainers and users of the library, and are therefore not complete. |
| 11 | + |
| 12 | +The idea here is to write a C++ wrapper to `libgit2` to provide a CLI, starting with simple `git` |
| 13 | +functionality and expanding the scope over time. All development work can occur on POSIX systems |
| 14 | +away from a WebAssembly toolchain, and the final step is to use |
| 15 | +[Emscripten-forge](https://emscripten-forge.org/) recipes to build it for |
| 16 | +[cockle](https://github.com/jupyterlite/cockle), just like other commands. |
| 17 | + |
| 18 | +There are two areas of functionality to be written in C++: |
| 19 | +1. Thin C++ wrappers of the various `libgit2` C objects to give automatical deallocation of |
| 20 | + resources as necessary. |
| 21 | +2. `git` command and subcommand implementations using [CLI11](https://github.com/CLIUtils/CLI11) |
| 22 | + for argument parsing, as it used in [mamba](https://github.com/mamba-org/mamba) for example. |
| 23 | + |
| 24 | +`libgit2` is well tested and well maintained, so we do not envisage unit testing of our C++ |
| 25 | +wrappers. The testing is therefore of the CLI, and hence does not have to be performed in C++ but |
| 26 | +can use `python` or `node` or similar instead. |
| 27 | + |
| 28 | +We will ignore some aspects of `git` initially that are hard to implement in a single-thread |
| 29 | +WebAssembly runtime, such as opening an editor for `git rebase` and so on. Instead we will |
| 30 | +probably use a fairly simple sequence of prompts and accepting `stdin` inputs from the user, and |
| 31 | +work towards full integration with editors at a later date. |
| 32 | + |
| 33 | +The `git2cpp` name of the project and executable follow from `libgit2` which includes its own `git2` |
| 34 | +and hence it would not be sensible to duplicate that name. In a terminal in which this is the only |
| 35 | +`git` implementation available we would expect users to set up aliases so that the usual `git` |
| 36 | +command name can be used. |
| 37 | + |
| 38 | +The alternative approach which we have rejected would be to start with the `git` source code itself, |
| 39 | +and build that for WebAssembly. That would involve removing functionality such as starting new |
| 40 | +processes to open editors by patching the source code for the WebAssembly build. That approach would |
| 41 | +be a much less pleasant developer experience than the one proposed here, given that all work would |
| 42 | +have to occur using a WebAssembly toolchain. |
| 43 | + |
| 44 | +All design decisions here are subject to change based on who the main developers will be and their |
| 45 | +preferred tools, etc. |
0 commit comments