You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
`gix-protocol` should support it one day, probably with a
crate implementing the protocol, which is then used from
the functionsin the crate. Ideally abstracting it fully.
`gix-protocol` should support it one day, probably with a
crate implementing the protocol, which is then used from
the functionsin the crate. Ideally abstracting it fully.
`gix-protocol` should support it one day, probably with a
crate implementing the protocol, which is then used from
the functionsin the crate. Ideally abstracting it fully.
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.The text was updated successfully, but these errors were encountered: