Implement the option to use Splitsh

[thomasmeeus]

Hi,

This PR adds the ability to use Splitsh as a binary to do the actual splitting instead of the really slow subtree split command. This was also a feature requested in #31

We're currently using this for 2 days in production already to split a monolithic puppet repo into 100 separate repositories and it's working fine. I saw a performance increase of about 5-10 times over the subtree split command.

Two downsides of this PR:

• We do not use tags and I didn't find the option in Splitsh either. Because of this tag-support is disabled when Splitsh is activated.
• I converted all tabs to spaces, because tabs are ugly. Hence the large set of changed lines :-)

[TomasVotruba]

I'm writing PHP wrapper over git subsplit and I came across this interesting idea.
What state is this in?

Would it create dependency on Go? In my experience, it's yet another language to install just to split repositories. Just saying.

@simensen Are you able to review this PR and tell us what could be the next step?

[thomasmeeus]

Just letting you know that this is still running fine multiple times a day. The performance is great (thx to splitsh). No Go dependency is required. It uses a precompiled binary version.

[TomasVotruba]

Sounds interesting. I'd like to try it, but I need to publish tags as well.

Symfony uses the same script for tags as well, right?

How to do that?

[thomasmeeus]

I don't know what Symfony currently uses. Tags work fine with subtree split. Only splitsh doesn't support it (back at the time I wrote this. I would have to check the current version)
A few years ago I splitted a Symfony repo with this tool, but only with subtree split in the backend

[TomasVotruba]

I see.

Only splitsh doesn't support it (back at the time I wrote this. I would have to check the current version)

Could you verify that please? If a tag support would be in and go is not needed, I'd pick this solution to my package.

[stof]

According to the readme of the splitsh/lite tool, --target and --origin support using tags references too

[luckydonald]

But with a pre-build go package we'd have to create one for every known system? Darwin, Windows, *Nix, that special thing raspberry pies use, etc?

In the past Go was known for dropping platform support quite without care, so I'd be a bit hesitant.