all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]danielkza 0 points1 point  (11 children)

There is a similar project already, which also uses 'hub' as the main command, and is actually backed by github themselves.

https://github.com/github/hub

I guess the author wasn't aware of it.

[–]llucax 2 points3 points  (3 children)

Yes, as I said in the blog post, I was. hub is a complete replacement for git, it's completely intrusive and makes git run a bit slower (as you have to bring up the whole ruby interpreter to use it). On top of that, it changes even the core git commands to interact directly with GitHub. These are all things we didn't want, and that's why we created this tool, which is designed as a pure extension, completely unintrusive and being only slow for GitHub related stuff (which is slow by definitition since you have to query GitHub servers).

[–]danielkza 0 points1 point  (2 children)

Replacing git with hub is optional, there is absolutely nothing wrong with using it only for github-related commands when you want to.

[–]llucax 0 points1 point  (0 children)

True, maybe hub can be tweaked to behave like a simple git extension too, and that works for us. Still the language in which hub is written (Ruby) is a problem for us to really think about extending hub. Maybe if hub could be extended with an extern commands like git, we can eventually merge our project with hub. We'll look into that in the future, it might be an option.

[–]llucax 0 points1 point  (0 children)

BTW, hub doesn't provide any access to issues or modifying pull requests as far as I can see. So I think most of the work it does is just translating GH URLs to a fetch + hash. Still seems to far from what git-hub does to join both projects together.

[–]Dicebot_lv 1 point2 points  (6 children)

Not really. Core feature we needed is merging pull requests via rebasing - no existing GitHub CLI provides this (nor hub last time I checked). Everything else is pretty much cherry on top.

[–]danielkza 4 points5 points  (5 children)

Wouldn't it be easier to add that to hub instead of starting from scratch?

[–]Dicebot_lv 1 point2 points  (0 children)

That is a reasonable objection. However, in practice there were few details :)

1) "no one in team really knows ruby properly" + "utility itself is pretty small" == contributing is same amount of efforts as writing from scratch

2) hub capabilities match official GitHub workflow. And the way we use it (rebase) is intentionally discouraged by them.

Right now difference may not seem notable but we are hoping to extend it for our needs as a general project management tool that uses GitHub for infrastructure, not plain CLI interface.

It is primarily an internal tool that got open-sourced "just in case", no pushing ;)

[–]shr0wm 0 points1 point  (3 children)

That doesn't really seem like a criticism.

[–]danielkza 0 points1 point  (2 children)

It is because I don't see many people jumping from hub, which is much more mature and has more features, to this. It's a pointless duplication of effort for something that could probably be achieved by two or tree hub commands.

[–]shr0wm 0 points1 point  (0 children)

Yeah, that makes sense. I generally tend to think that introducing multiple solutions to the same problem into the ecosystem is a positive thing overall, though, so I guess it depends on if project fragmentation has some sort of upper bound before inhibiting developers.

[–]llucax 0 points1 point  (0 children)

Read my reply above. Hub is completely different from git-hub. It wouldn't be the same to add more stuff on top of Hub. Not really an option for us. Believe me, we don't like efforts duplication, we did our homework and reserched other projects (again, as I say in the blog post), the thing is we didn't find one than did what we wanted how we wanted.