Add `setup-fork` command, reimplement `clone` command as its child

[oxij]

This command greatly simplifies setup for a previously clonned repository.

A somewhat unforturate consequence is that the name of the only hub.hookscript had to be changed since invoking that hook is part setup-fork now. Since I had to rename it anyway I also renamed it to match git's own hook naming convention of using "-"es to separate words.

I tested this a bunch (as shown with newly added examples) but do test some more before merging.

[oxij]

This closes #235 and #43. And probably closes #158, since running git-hub setup-fork will do the right thing in the most common case (and gracefully fail otherwise).

[llucax]

Oh, the CI is also failing. There seems to be a problem generating the man page, there is probably some issue with the man.rst ReST formatting.

[llucax]

I'm trying this out with the case of using no fork and I'm having issues creating a PR. It seems the hub.user config variable is still used in the head property in the json sent to create the PR, which makes it fail as there is no fork.

[llucax]

I'm trying this out with the case of using no fork and I'm having issues creating a PR. It seems the hub.user config variable is still used in the head property in the json sent to create the PR, which makes it fail as there is no fork.

This is actually a different use case. I tried an only-upstream configuration, and it is actually possible to achieve by setting the git config hub.forkrepo <upstream>. I think it makes sense too to add another option to configure forkremote via setup-fork too, for example:

If you want to set up an *upstream-only* repo (no fork is present, centralized approach)::

    git clone https://github.com/sociomantic-tsunami/git-hub
    cd git-hub
    git-hub setup-fork -U origin -F origin -f sociomantic/git-hub

 This will create new branches in the upstream repo directly and no fork will be used. ``--triangular`` will be force to ``false``.

Where -f/--fork-remote sets the hub.forkremote git configuration.

[llucax]

ping @oxij ? :cry:

[oxij]

Those are good suggestions, except I'm not sure how do I go about implementing the "hook"-related one, the hook script is a single string there.

Anyway, I was thinking, it probably makes more sense to just collect all of those and other related commands into a subcommand, like git hub repo.

E.g: git hub repo fork <remote-url>, git hub repo setup <lots of options>, git hub repo clone <remote-url>, etc.

[llucax]

Those are good suggestions, except I'm not sure how do I go about implementing the "hook"-related one, the hook script is a single string there.

You just accept both postclone and post-setup-fork and if postclone was used, print a warning about it being deprecated.

Anyway, I was thinking, it probably makes more sense to just collect all of those and other related commands into a subcommand, like git hub repo.

I'm neutral about this, it would be probably nicer if managing how the git repo is related to the GitHub repo gets more complicated but again it would be a breaking change, so at least git hub clone should be still supported (although deprecated). Because of this I don't mind keeping it dirty for now (and do a cleanup on a future major release). I prefer merging these changes sooner than later, even if not perfect.

Also, please let me know if I can help in any way, if you don't mind me pushing commits to your branch I can do some of the cleanups/changes I suggested.

[oxij]

Those are good suggestions, except I'm not sure how do I go about implementing the "hook"-related one, the hook script is a single string there.

You just accept both postclone and post-setup-fork and if postclone was used, print a warning about it being deprecated.

Yes, but the hook is a script. Do you want to run it with both arguments? How do you check it did anything at all to deprecate the old one? git's own hooks are files, there it's easy to check the file exists, the hook thing here is a shell script, you could do some primitive code analysis on it, but, well...

Anyway, I was thinking, it probably makes more sense to just collect all of those and other related commands into a subcommand, like git hub repo.

I'm neutral about this, it would be probably nicer if managing how the git repo is related to the GitHub repo gets more complicated but again it would be a breaking change, so at least git hub clone should be still supported (although deprecated). Because of this I don't mind keeping it dirty for now (and do a cleanup on a future major release). I prefer merging these changes sooner than later, even if not perfect.

Alright.

Also, please let me know if I can help in any way, if you don't mind me pushing commits to your branch I can do some of the cleanups/changes I suggested.

Sure, feel free to do whatever with the code here. I'm a bit busy with other stuff ATM.

[llucax]

Yes, but the hook is a script. Do you want to run it with both arguments? How do you check it did anything at all to deprecate the old one? git's own hooks are files, there it's easy to check the file exists, the hook thing here is a shell script, you could do some primitive code analysis on it, but, well...

Right, right, right. I completely forgot it was one script and the type of hook was passed as argument (my impression was this feature was too niche to deserve having many hook scripts).

Then yes, calling the script twice would be an option (although not very nice). To be honest the cost/benefit of the rename at this point doesn't seem to be worthy. Specially since the dash-style used by git is applied to files and in this case is an argument to the file that is configured by the user, the rename seems specially pointless, right?

Sure, feel free to do whatever with the code here. I'm a bit busy with other stuff ATM.

Cool, I will make some of the suggested change when I have some spare time!