guyzmo

a coconut!

I'm guilty of the Lua feature, and even though it's only covering the existing muttrc API, it can already do quite a lot. The Lua feature is (not yet) turned on by default at compile time (and thus in systems distributions).

I'd be very happy to have more feedback and help to extend further that API and have some great scripts happening!

Oh, I need to make a ticket about adding that to the wizard. Be my guest if you want to :-)

<3 I guess you're referring to my other project :-)

Yes there is! There's a bug that has been found that crashes the feature, but I got a patch ready to publish.

thank you. Please suggest a better name! :-D

Well, for the easy to remember, I might have been presomptuous O:-)

Well as I said for another post I'm aware of that. As the google project is mostly used only for android and chromium, and as the canonical name of the tool really is /repo/ and not /git-repo/, there's no real name clashing.

The only issue might be my project being shadowed by google and go, but the more people will like and use the tool I baked with , the more it'll appear on their first page. So it's not really up to me, but up to you all liking it!

And finally, if someone comes with a nicer better name than what I chose (I actually did not spend more than 2.42 minutes on the name when I had to mkdir the project's directory), I might be happy to rename :)

Otherwise, I hope you'll like the tool and send me patches and <3

Well, TBH, as an engineer, I hate to reinvent the wheel. I prefer to join and improve the existing concept with my own ideas to make it the synthesis of many peoples ideas

You might see on my github that I do that a lot, I'm being some sort of mercenary of FLOSS projects, as I patch wherever I see a bug or want a new feature without really caring about the "big plan"

Actually, I wrote the tool because deep down I just want to /use/ the tool.

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!

hehe, it's also implemented in git-repo: `git hub open`

note that I did not say that git has a good UX, I said it's /rather well designed/… Maybe should I have emphazised on the /rather/, or used something stronger like /relatively/ .

But anyway, designing the command line API of my own tool took me enough headaches — and I'm still not 100% satisfied — to understand how hard it is to have a consistent and great UX for something that offer as many features as git does. Though, I'm trying my best to avoid the decade old troll about git's UX (like vs mercurial)…

In the end, what I try to make clear it's that I'm not trying to replace what git does, but cluster a bunch of repository actions tied with some service's API operations.

And I try my best to offer a pleasant UX doing so. But please, help me making it better!

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…

Bitbucket support is there. But it's not feature complete, and not up to my standards…

The issue I have is that I got to implement OAuth2 for bitbucket, because the privatekey scheme offered by bitbucket does not work for a CLI tool use case. So currently, the credentials (login/password) of bitbucket are stored in CLEAR in the configuration file, which really, really sucks…

And some new features (like the snippets) are not implemented in third part python libraries, because most of the libs are old and unmaintained.

Anyway, following some discussions I had with atlassian bitbucket developers, bitbucket (like gitlab) is planning to switch to swagger, which will help automagical generation of client-side feature complete libraries. So I'm planning to level bitbucket feature set as soon as they land the new API.

So I hope it won't be long before all the features will land for the three services!