Adjust gitify with more git commadns

[Raynos]

I want to update gitify so that it can run effectively https://gist.github.com/Raynos/10416135

I'll make a PR for this and add a bunch of options / if statements.

I want to shell out to hub for creation since they use oauth properly instead of sending my password over https.

If this workflow is out of scope I'll make a seperate repo instead.

[thlorenz]

I want to shell out to hub

NOOOOOOOOOOOOOO

The whole point of gitify is not to have hub installed and to work everywhere where node is.

they use oauth properly instead of sending my password over https

Couldn't we fix this in gitify? That PR I'd definitely merge.

On another note the mission of gitify is very narrow "gitify your repo" it should not become another github API thing.

So if you want to write a wrapper around hub that'd be ok, but that wouldn't belong into gitify.

On another note if you find a C lib that is more fuller featured, lmk. I wanted to hone my skills at writing a node addon and that would be a good chance

[Raynos]

@thlorenz it only shells out to hub if it exists. it will use gitifys version if it doesn't exist.

All of this will be driven by options.

I want to shell out to hub because its a github maintained tool that should handle authentication concerns correctly. I rather not deal with authentication for sensitive information like github credentials in node.

[thlorenz]

Ok that's different then. I suppose we'd add this to the gitify options ~/.config/gitify.js.

So by default it'd use hub if it's there, but I could nuke even that.

In that case all is good and I'd merge that PR.

[Raynos]

So I want to clean up the cli a bit by adding -h and usage documentation.

# {cmd} [options] [repo] [description]

Creates a git repo and pushes it to a github remote.

Options:
    --hub           If set uses `hub` to create repo
    --message       change the git commit message
    --directory     which directory should become a git project
    --no-create     does not create a github remote
{options}

 - `--hub` defaults to `false`
 - `--message` defaults to `'initial repository'`
 - `--directory` defaults to `CWD`
 - `--no-create` defaults to `false`

## {cmd} --help

Prints this message

I want to break back compat on the cli by not allowing user & password as CLI arguments, seems far better to prompt for those.

[thlorenz]

IMO the decision to use hub if it is present or not is a one time decision. By default we should use it, but document that users can edit the config file to change this.

Making this a command line arg is not a good idea I think, since you'd have to supply this for each repo you gitify, but most likely you'd want the same setting each time.

So let's keep only settings in the command line that are relevant for the particular repo.

--dirname is not necessary IMO just cd into the folder to gitify although if you really want this I can live with it. --no-create not sure why you'd need that just use git init when you don't want a remote or am I missing something?

I want to break back compat

You can break it all you want, as long as I can still do: gitify <repo> <description>

So as long as that works, i.e. options are all prefixed with -- and can occur anywhere but the first two non-prefixed ones are considered to be repo and description, then that's fine.

[Raynos]

@thlorenz --no-create is useful if you want to create a NON GITHUB repository.

This by passes the "try to create github" step and just pushes directly to the remote.

If you have a gitolite private git server installed this will "just work (tm)".

I choose to add the --hub flag so that this new behaviour of using hub instead of the current create github remote logic is opt in and defaults to false.

Also if --hub is set to true but the hub binary does not exist it will error out instead of falling back to the default javascript github repo creation.

[thlorenz]

Ok, so --no-create is fine, but not sure about the hub thing.

There is nothing at all wrong with using hub if it is there.

A very few advanced users may want to change that and they should be advanced enough to edit the config. Surely that is better than having them turning off hub each time they create a repo.

[thlorenz]

To be clear we'd default to using hub if it is found in the user's path.

[Raynos]

@thlorenz what if I add a --always-hub flag that says "always use hub, error if it doesnt exist"

[Raynos]

also

{ err: 
   { message: 'Must specify two-factor authentication OTP code.',
     documentation_url: 'https://developer.github.com/v3/auth#working-with-two-factor-authentication' },
  statusCode: 401 }

:) can't test the old create flow locally because of 2factor :D

[thlorenz]

Ah that's sad :( Maybe create an account w/out two factor to test it - but anyhoo not too important. I won't be able to run the new tests then I guess, so we'll have to trust each other :P

So my main point is to not have hub anything as a command flag since most likely you'll wanna use it if you installed it. Instead override that via the config if you don't want it (rare case). And then it will apply every time you gitify anything.

[Raynos]

@thlorenz I want gitify to fail and error hard if hub doesn't exist. hence an --always-hub flag for that new back compat breaking funcionality.

I could just not document this flag if you want :D

[thlorenz]

I think I get it now, you are trying to meet some uber security requirements I suppose?

Aren't you worried about people forgetting to add that flag? Or are you adding aliases? Wouldn't that be even more of an argument to add this to the config since then ppl will not forget to set alwayshub ever?

On the other hand it's not such a huge deal, so if you want it you can add it (and document it as well).

[Raynos]

@thlorenz I'm going to wrap gitify in a play-doh create wrapper that sets default options and then calls bin/gitify.js

PR upcoming.

[thlorenz]

Cool.

Never used play-do while working at my computer. Afraid it'd clog up my keyboard.

[Raynos]

play-doh is an internal wrapper around a bunch of open source modules.

Once I figure out how to seperate the thing from all the internal infrastructure i'll open source it.

In the meanwhile I'm building the core as a set of modules and glueing it together in a private module :)