Hoping this makes it more obvious when code touches the very
unsafe contents of this variable.

Passing strings to Kernel::exec leads to remote code execution.

This reverts commit 8449979ff029af51be0c675c5b6262bc4adc8b3d.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Add fetch-remote command for repo mirroring

Also exits `import-repository` with non-zero status when import fails.

See merge request !29

This reverts commit ae498b6cd4122d3d7f35e6b73b50c53615ca3488, reversing
changes made to 79fdf65c71e90773fbf52d6832b74cf5a7124755.

Add support to connect gitlab-shell to Unicorn via UNIX socket  (v2)

Hello up there.

I'm doing SlapOS port of GitLab, and that means several different services could be running on the same machine, including several GitLabs.

So far all internal GitLab subservices could be glued together via UNIX sockets except gitlab-shell -> Unicorn link, which, when done via local TCP, requires firewall/network namespaces to protect services on one machine from each other.

On the other hand access to UNIX domain sockets is managed via regular UNIX permissions on filesystem, and thus is easier to manage. Besides UNIX domain sockets are well known to be faster compared to TCP over loopback - in particular to have ~ 2 times less latency and ~ 2 times more throughput.

From this point of view it makes sense to teach gitlab-shell to talk to Unicorn via UNIX socket and switch to that mode by default eventually.

I've just made a patch for this. Please apply.

Thanks beforehand,  
Kirill

/cc @dzaporozhets, @jacobvosmaer, @rspeicher 

See merge request !30