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!
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!
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!
And I hope also level the game for alternatives to github. Git is distributed by nature, and we should only be happy to see cross services forks happening!
See the issues, it's already implemented, but not released yet. The issue is that I also am working on the gitlab snippets… which lacks an API. So I'm currently working on a patch to add an API to the gitlab snippets, so my tool can have gitlab snippets!
Well, first the name really is `git-repo` not `repo`, and as nobody has really heard of it yet, the pypi package is already on first page of go, and second page of google.
I hope that if people like the tool, it's going to be easier to find.
Of course, I'm not really obsessed with the name (as anyway the tool is designed so the user does not type git-repo everyday ). So if someone comes up with a name that's great that can be better, I'm all ears!
About the fact that google has that other tool… Well they really are not much projects using it, beyond the google projects, and the tool really is called `repo`, not `git-repo`, so the name clash is not really there.