list github issues and allow for issue branch creation

[gorenje]

Intention is to better support creating feature branches and attaching commits to issues. Thus better supporting the github flow.

The exact flow on the command line is outlined here: https://gist.github.com/2595128

basically the intention is
1. create branch names that include the issue number
2. automagically include the issue number with a refs #... in every commit on that branch
3. attach all commits to the original issue
4. convert the issue to a pull request.

[gorenje]

eating dogfood, this commit was generated by doing (having installed the commit hook at https://gist.github.com/1012062):

prompt> git clone https://github.com/defunkt/hub
prompt> cd hub/
prompt> hub fork
... made some changes ...
prompt> hub github-issues -u defunkt
prompt> hub feature-branch -i 170 -u defunkt
prompt> gitc -a -m 'first version of the extra commands to support https://gist.github.com/2595128'
prompt> git push gorenje issue_170_list_github_issues_and_allow_fo

[mislav]

Two problems with this:

• this flow is pretty evolved. hub avoids all but the most general workflows with git & GitHub
• listing issues is outside the scope of hub. see Add support for issues management #142

So. Although your heart is in the right place, I don't want to go down this path. First of all, because I don't use such flow myself. Second, because it's more for me to maintain.

[gorenje]

okley, thanks for the feedback.

how about having a pluging architecture so such things could be included via plugins? that would make adapting the github flow for specific situations easy ...

[mislav]

I'm open to suggestions how to make hub more flexible. However, this topic is still a bit too abstract for me to think about. If you have concrete suggestions where in code would you want to hook in, let me know.

[gorenje]

i guess #39 would be an approach, however extending would then still mean forking and adding command separately.

but with #39 it would be possible to have a separate ~/.hub/commands/* directory which could be loaded
via a ~/.hubrc file. however it probably would be necessary to load a per-project configuration file (different flows
with different teams) ... so it would be a case of having the hub.config=... git configuration option, where the
global configuration is default.

but having a hubrc would again be overhead, so maybe a git option something like hub.commands.dir=.... which
points to the directory of extra commands could be a quick start (if #39 were to be done).

either way, hub is such a useful tool that not be able to extend it with project-based extensions really
limits it's application within a project, imho.

[gorenje]

the commit @eec8632 is what i am now doing, it looks for the hub.commands configuration value and then retrieves any extensions from there. Works well enough and i can now include my own commands without touching the existing flow.

https://gist.github.com/2621377 is an example of a new command that gets load. Basically all changes from my original commit but outsourced.

[mislav]

I see. I might think about a plugin architecture for hub. I'm also thinking how to make Hub::Context methods easily available to subscripts without having to install the "hub" rubygem. But it's not gonna happen right now, as it isn't my priority.

As for your need, I strongly suggest doing it as a separate script. This way you don't rely on hub and its internals, which will probably change soon and might break your plugins. Separate script is way better option because you're in control.