More scaffolding

This pull request asserts a couple of opinions, including...

* major
  - using `libgit2` and `git2go` for future `git` operations (asserting that this is the correct course of action over using `exec.Cmd`, as it will be much faster, albeit slightly more involved to compile for releases)
* minor
  - `Makefile` style
  - not installing with `gem` (update in documentation)
  - using `ginkgo` as the testing library of choice

request comments.

**edit:**

Additional assertions:

* major
  - there will be two executables, `git-duet` and `git-solo`
  - the top level package for shared libraries will be called `lib`
* minor
  - *(none)*
Agreed again.  I think bats is a great fit.  If unit tests end up being
necessary, I'm OK with ginkgo as long as the rumors of `go test`
compatibility are true :smiley_cat:.
On Jun 10, 2014 10:07 AM, "Jesse Szwedko" <notifications@github.com> wrote:

> In Makefile:
>
> > +lint:
> > +	@echo "----------"
> > +	@echo "checking lint"
> > +	@for file in $(shell git ls-files '*.go') ; do \
> > +	  if [[ "$$($(GOPATH)/bin/golint $$file)" =~ ^[[:blank:]]*$$ ]] ; then \
> > +	  echo yayyy >/dev/null ; \
> > +	  else $(MAKE) lintv && exit 1 ; fi \
> > +	  done
> > +
> > +.PHONY: lintv
> > +lintv:
> > +	@echo "----------"
> > +	@for file in $(shell git ls-files '*.go') ; do $(GOPATH)/bin/golint $$file ; done
> > +
> > +.PHONY: ginkgo
> > +ginkgo:
>
> I'm not sure we will need tests inside of Go for this project given its
> size and the bats tests already in place.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/modcloth/go-git-duet/pull/1/files#r13594952>.
>