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?

[koppor]

What do you think?

Thank you for the long answer! It seems like a nice project to learn Rust. If I only had time 😅

[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.