[KZeillmann]

I really enjoy how the author broke down both the problem and the solution, explaining why the existing solutions are inadequate. I often see articles about new products or new programming languages, and their features, but they often forget to mention what problem prompted the solution. Why was a new language invented to solve this problem? Why were the existing solutions limiting?

Bravo to the author here for making all that information clear and up-front.

[Aldo_MX]

> I really enjoy how the author broke down both the problem and the solution, explaining why the existing solutions are inadequate.

A thousand times this, I always get frustrated that every single product, tool or service has to have a lot of marketing gibberish, catchy slogans, etc., but zero explanations of what problems do they attempt to solve, or what was the motivation to create them.

You usually are required to dig further in the documentation or look for an external reference to understand what's the real purpose behind a product, tool or service.

[guyzmo]

thank you a lot for your comments

I actually wrote that tool based on a huge frustration I had going back and forth to the browser, and not being able to work while being agnostic to the services, which felt being a totally broken UX. I have then worked on that tool for a while, used it and refactored it a lot up until I'm happy using it.

All in all, when I'm doing a tool, I'm first doing it for myself (I might invent the DIFY concept, to override the DIY concept )… only then I'm sharing it with others.

[mst]

The same situation kinda drove me insane too, but I've been happily using -

https://github.com/ingydotnet/git-hub/

for a while now. It might be interesting to compare and contrast your tooling and git-hub - ingy's being straight bash, while a little crazy, makes installation really trivial, but then again yours supports multiple services, but then again who knows whether the different subcommand syntaxes will work better or worse for any particular other user.

(also, lest anybody think this is a veiled complaint, I'm sure ingy's reaction to finding your work exists will be "awesome, the more the merrier" followed by figuring out if you came up with any features he wants to steal ;)

[guyzmo]

Thank you, though pretty close, our approaches are slightly different. My main focus is use case, I did not implement the social features of a repository, because those are things that happen happily in a browser.

But project/merge requests/gists are things that have a lot of sense to happen in the commandline /instead/ of within the browser. So basically, his solution is more feature complete on the social side, whereas I implemented more the repository interaction side (like creating gists, or fetching a PR).

So for sure he's got a point for portability being a bash script, but still python3 is begining to be widespread enough.

I mean, if debian-stable got it, you can consider it's everywhere…

[mst]

Not sure if it's something you'd call a social feature, but I find things like listrepos on an organization to be really helpful for piping into xargs to checkout everything a new customer depends on.

The PR stuff is so far as I can see complete in git-hub - what do you think you're missing?

(edit: if you meant gists, lots of the people I know already use paste site CLIs that handle that, btw, so to -us- that's more a social feature than the existing functionality is)

[guyzmo]

My bad, I did not scroll down to see how complete the command set was. At the top of the readme the list of commands is misleading (I thought there were only those at the first read).

I'm not sure I can see a real use for checking out every repo of an organisation (I mean, if you do that with mozilla, you better start before going for a long holiday ), but having it /possible/ is a great thing

So I guess we're pretty much alike, git-repo being strong for being service agnostic, and git-hub being more complete.

Though, in my redesign plan I got for version 2, I have in mind a framework to make it possible to implement service-specific CLI API, while sharing a same core CLI API for the service-agnostic features.

So my hope is that people will like the tool enough to participate in the development and help make the tool more feature complete across the services!

[edibleEnergy]

came here to mention 'git-hub' as a "see also" as well :)

[tinita]

I'm using git-hub as well and I find it very DWIM and more complete. (Have to add that I'm also a collaborator now, so maybe a bit biased)

I couldn't figure out how to use git-repo. When I figured out which command I have to use to list pull requests for github, it asked me for my ssh key password. I was wondering why it would need my ssh key at all, so I tried -v, but -v did nothing.

Then I gave up.

Also, it lacks tab completion, as far as I can see, while git-hub supports it for bash and zsh. And since the order of the commandline arguments is not fixed (`request list` vs. `request <user>/<repo> list`) it might be actually difficult to add completion. I'm developing a generic completion generator, which would allow to add completion to existing commands, but it's not able to deal with this dynamic commandline argument order.