Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider supporting the remote-helper format #1666

Open
nikhiljha opened this issue Nov 10, 2024 · 1 comment
Open

Consider supporting the remote-helper format #1666

nikhiljha opened this issue Nov 10, 2024 · 1 comment
Labels
acknowledged an issue is accepted as shortcoming to be fixed enhancement New feature or request

Comments

@nikhiljha
Copy link

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.

@nikhiljha nikhiljha added the enhancement New feature or request label Nov 10, 2024
@Byron Byron added the acknowledged an issue is accepted as shortcoming to be fixed label Nov 11, 2024
@Byron
Copy link
Member

Byron commented Nov 11, 2024

Thanks for the reminder, I absolutely agree that gitoxide will eventually have to learn it.

Byron added a commit that referenced this issue Nov 12, 2024
`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.
Byron added a commit that referenced this issue Nov 12, 2024
`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.
Byron added a commit that referenced this issue Nov 15, 2024
`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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledged an issue is accepted as shortcoming to be fixed enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants