It would be neat if gitoxide could talk to regular gitremote-helpers. These speak a simple newline-and-space separated protocol, and anyone can implement their own backends with the C git client by writing one. In fact, there are even some gitremote-helpers already written in Rust, since there's no reason a helper needs to be written in C.
This is probably a very niche feature, which is why the title says "consider", but I do think it has benefits and cannot really think of any downsides.
Motivation 🔦
Using this format would allow for falling back to the regular git-remote-https/git-remote-ssh backend if there's an unimplemented feature, or using the gitoxide implementation of https with the regular git client.
This also would allow gix to work for people using non-https-or-ssh transports without needing to reimplement their transports in Rust. For example: git-remote-keybase, git-remote-rad, git-remote-codecommit, git-remote-s3, etc.
Summary 💡
It would be neat if gitoxide could talk to regular
gitremote-helpers
. These speak a simple newline-and-space separated protocol, and anyone can implement their own backends with the C git client by writing one. In fact, there are even some gitremote-helpers already written in Rust, since there's no reason a helper needs to be written in C.Spec: https://git-scm.com/docs/gitremote-helpers
This is probably a very niche feature, which is why the title says "consider", but I do think it has benefits and cannot really think of any downsides.
Motivation 🔦
Using this format would allow for falling back to the regular
git-remote-https
/git-remote-ssh
backend if there's an unimplemented feature, or using the gitoxide implementation of https with the regular git client.This also would allow
gix
to work for people using non-https-or-ssh transports without needing to reimplement their transports in Rust. For example: git-remote-keybase, git-remote-rad, git-remote-codecommit, git-remote-s3, etc.