Add all failed

[Nevercold]

Hey,

i get on $repo->addAllChanges(); "Command 'git add --all ' failed (exit-code 128)"

How i can fix it?

[janpecha]

Hello, works git add --all in command line if you run it manually?

[chippyash]

I have exactly the same issue. More Info:

• Using a debugger I stepped through code to L660 in GitRepository.
• The exec fails and throws error as above.
• Inspecting the $output variable reveals message (part) "*** Please tell me who you are."
  with instructions on adding email and name etc. The email address it finds is incorrect, i.e. not the one set in my global git config.

so:
1/ It would be useful to add content of output into the exception to aid devs without a debugger.
2/ Why is this failing? I'm using ssh. The clone works just fine.

My particular setup:

• I have an application under git control
• My application clones another repo into a subdirectory of the current application
• The user running the application is me

I added exec('whoami', $output, $ret); into the run() method at various points. This shows that the user running the command is not me, but the machine host name. The cloneRepository() method uses a different method to execute the command (proc_open rather than exec). I suspect that this is the root of the problem.

I am successfully using PHPStorm running tests via CodeCeption Unit by the way

[chippyash]

There is a HACK to get round this:

You need to set the user.name and user.email for the newly cloned repo. In my code I do:

$this->repository = GitRepository::cloneRepository($this->repoUrl, $this->clonePath, ['--branch' => 'master', '--single-branch']);

 //set the username and email for later operations
$this->repository->execute(['config', 'user.name', $this->uname]);
$this->repository->execute(['config', 'user.email', $this->uemail])

This appears to work, however it is a hack in my use case, as I want this process to be running on a production server where the ssh keys and git user to connect to the git repository have been set up for process running the web server to do the work. Developers don't know who that user is (and shouldn't,) so this would mean either exposing the production user account to devs to configure, or doing some chicanery when setting up the DI container for the application, neither of which are ideal. The solution may help others whilst the issue is being sorted.

I suspect that I'm going to run into problems issuing a push however, due to lack of ssh key access. (push() uses exec method again.)