gix submodule add

[moto-timo]

I am currently writing a Rust CLI tool to manage projects using git submodules (for the Yocto Project / OpenEmbedded where we use different layers from different git repositories).

One of the things I miss from most of the "git wrapper" libraries is git submodule add. I would like to try to help contribute this functionality to gitoxide, but I am still trying to digest the structure (e.g. ein init but not gix init? why not expose gitoxide_core as a crate? and what is gix-submodule just the definition of submodule objects?).

I am also quite new to Rust, so the learning curve is still steep-ish.

I would love to hear your thoughts on how git submodule add should be implemented in gitoxide so that I go down a path that you would prefer, instead of some random approach that makes sense to me at the moment.

[moto-timo]

References:
https://github.com/git/git/blob/master/git-submodule.sh
https://github.com/git/git/blob/master/submodule.c
https://github.com/git/git/blob/master/submodule-config.c
https://github.com/git/git/blob/master/builtin/submodule--helper.c

[Byron]

There is definitely some vital pieces missing in DEVELOPMENT.md, but let me sum up the structure here real quick. Maybe a possible first contribution could be an update to said file to include this information.

Structure

• gix-* crates are all plumbing -they deal with one part of Git and are low-level
• gix is the crate that brings all plumbing crates together, and is what libraries or application developers would use.
• gix and ein are binaries defined in the gitoxide crate (top-level of this repository)
  • gix is a developer tools that does not try to be git. It helps to run newly added features in the real world, outside of unit-tests.
  • ein is explicitly the git binary I always wanted, providing useful tools and one day, a Git developer workflow.
• gitoxide-core is a crate that implements everything in the gix and ein binaries, and it's probably not useful for external use.

About Submodule Add

The general idea is that as much as possible should be implemented in the respective plumbing crate, gix-submodule in this case. Everything there is covered by unit-tests, and the implementation is based on the C implementation (see references provided by you). Once the building blocks of adding a submodule, to the extend possible, are in the plumbing crate, one would bring this into the gix crate to complete the implementation.

About Contributions

Thanks for proposing to contribute submodule add! My recommendation here is to dabble in what that would mean first in your own codebase and try to use what's there of gix to do it. Everything you'd need is already present, like writing git configuration files and initializing/cloning/fetching repositories. This would probably already work for you with smallest-possible effort.

Contributing such a feature to gitoxide and see it through to completion is definitely a lot more effort, but having a 'quick-but-working' solution to work with as basis will certainly help.

I hope that helps.

[moto-timo]

Added a couple more references, since git submodule add is really just a call into the bash script and the real work is done by submodule--helper.

In my own project, I have at least managed to init/fetch/clone git trees to where I want them using purely gitoxide ;)
Now I need to digest handling the git config files and commits. Meanwhile, I am slowly catching up on all the Learn Rust with Gitoxide YouTube sessions.