Fix config option

[chriscool]

The first patch in this PR makes "ipfs -c=dir/.go-ipfs init" work.
The second patch adds some tests to catch any regression.

[whyrusleeping]

I recall making that change to commander in the past and it had some odd consequences...
I beleive @jbenet was weirded out that it required the '-c' option to be specified before any subcommand

[jbenet]

@chriscool we shouldn't modify anything under Godeps directly, as that's vendored code (Go's approach to package management). We should change the source repos and then re-vendor. Otherwise we'll get horribly off sync with upstreams.

We can modify my fork of commander here: https://github.com/jbenet/commander but, mappum's commands PR (#196) will move us into our own commands/ package soon. (i.e. the flag will change then -- for now use the ENV var)

Also, -c may conflict with child flags. I think we should just use --config as this is a strong enough (+ command wide) flag to warrant typing the extra characters.

(feel free to rebase the branch)

---

The test LGTM!

[chriscool]

Ok, this can wait until PR #196 and our own commands/ package.

About conflicting with child flags, I think "ipfs" command flags should be independent from child command flags.

For example with git ou can say:

git -c color.ui=false grep -c ok

where "-c color.ui=false" is a "git" command flag and the other "-c" is a "git grep" command flag.

By the way it could be useful for ipfs to have a way to change config values just for one command, like the above "-c name=value" "git" command flag.

[jbenet]

I think "ipfs" command flags should be independent from child command flags.

Yeah I was leaning towards this as well at first. (i.e. (<cmd1> [<flags1> ])+ [<args>])), which is logically better. But from a UX standpoint, many tools end up making flags usable all over, e.g cmd1 cmd2 cmd3 arg -flag3 -flag2, which (when coupled with non-conflicting flag names) makes life easier for the user.

@chriscool do you have more examples of clashing flag names in git? or is this a rare occurrence?

[chriscool]

It is a rare occurence because there are very few one letter flags for the "git" command: -c, -C and -p.
See: "$ git help"

By the way it looks like docker uses the same docker <option>... <cmd> <option>... <args>... pattern as git, and it looks like there could more often be conflicting options.
See: "$ docker help" and "$ docker help run"

[whyrusleeping]

👍

[whyrusleeping]

@chriscool I really gotta say that these tests youre writing are awesome

[jbenet]

Seconded, these are so useful!

[chriscool]

Thanks guys! I am happy that you like them.

I will write more of them, especially this week end.
In the end though, it should be like when developing Git these days, everyone who makes some significant changes or fixes a significant bug in the CLI should add some tests.

Btw I am often lurking at the IRC archive and I like what you are doing very much. It feels great to see how fast the project is moving! It reminds me when I started working on Git in 2006 :-)

[whyrusleeping]

@chriscool is this PR still something that could be merged? or should we just close it?

[whyrusleeping]

closing due to inactivity, if needed, reopen

[chriscool]

Yeah, sorry for not responding. I think it was too old and could not be merged anymore.

[whyrusleeping]

no worries, just working on cleaning up our stale PRs.