Support git remote -v

[koppor]

I like GitHub's CLI tool. We are discussing using gitoxide as backend for it. On GitHub's CLI side, this would cause a high maintenance effort (cli/cli#11050 (comment)). Thus, we are looking into whether its possible to have gitoxide CLI compatible for the commands used by GitHub CLI. I am aware that this is kind of a non-goal, but I wanted to ask nevertheless.

Currently, remote -v is not supported by gitoxide. Can it?

Risen by eirikb/gg#111 (comment)

[Byron]

Thanks for bringing this up.

Indeed, I still think this effort belongs into gitoxide, but would hope that the code already present in gitoxide-core can be reshaped to implement select git functionality perfectly.

When writing this I have to ask myself if such an effort would be better to have closer and more discoverable, maybe as a repository within the organisation. And the answer would clearly be 'yes' - that way it may attract more contributors and the people interested in this could maintain it themselves.

Thus, the answer seems to be that you are welcome to implement a git CLI yourself and to the extend you need, and after an incubation period you could also do that in a GitoxideLabs repository for discoverability.

What do you think?

[eirikb]

I'm no expert in Rust, but I could give it a try and add -v to remote. I don't know about adding or creating a git CLI, but in our case I really hope gix will do just fine with some small adjustments (hopefully just this).

[eirikb]

@Byron Would something like this work?
This is a working version, just need to brush it up:

eirikb@eh ~/d/t/gitoxide (main)> git remote -v
origin  https://github.com/GitoxideLabs/gitoxide (fetch)
origin  https://github.com/GitoxideLabs/gitoxide (push)

eirikb@eh ~/d/t/gitoxide (main)> ./target/debug/gix remote -v
origin  https://github.com/GitoxideLabs/gitoxide (fetch)
origin  https://github.com/GitoxideLabs/gitoxide (push)

[Byron]

I mean, I could say that if it's the only thing you will ever need there seems no harm in mixing it in like then. But then again, you would depend on a debug tool that may change at will if it's not tested. There is a journey-test suite that would allow to pin that new behaviour and I think that's a requirement then for stability (i.e. your own sake).

Something I don't like about it is that it doesn't fit into the way the commands are usually built, so here git remote -v would rather be gix remote list -v, unless for the sake of Git compatibility you'd also want to make gix remote list symbolic remote names.

So unless the new functionality is all under gix remote list, I'd be torn about this.

[eirikb]

I've been thinking a bit on what you said. And it makes a lot of sense.
I don't think gix should be modified to support this, and gg.cmd should not rely on gix at all.

I have looked at other options to make git available (portable), but haven't found any good ones.
Perhaps find latest deb for glibc, alpine package for libc, and extract these, extract installer for macOS, the GitPortable for Windows.... In other words it is a mess.

The other alternative, which is very tempting, but a huge undertaking, is to do as you say and make a separate git CLI - portable-git.
gix is already a step in the right direction.
Wouldn't need to implement a lot in the beginning, just to get a POC working.
Tempting.

[Byron]

That's great to hear, and maintaining such a binary yourself with just the features you need seems like it's the most future-proof option as well. Since the gg is written in Rust, it's easy to build additional binaries for distribution or … build what's needed into gg right away.