I am getting an error while executing a remote PowerShell script. From my local machine I am running a PowerShell script that uses Invoke-Command to cd into a directory on a remote Amazon Windows Server instance, and a subsequent Invoke-Command to execute script that lives on that server instance. The script on the server is trying to git clone a repository from GitHub. I can successfully do things in the server script like "ls" or even "git --version". However git clone, git pull, etc. result in the following error:

Cloning into 'MyRepo'... + CategoryInfo : NotSpecified: (Cloning into 'MyRepo'...:String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError

This is my first time using PowerShell or a Windows Server. Can anyone provide some direction on this problem.

The client script:

$s = new-pssession -computername $server -credential $user
invoke-command -session $s -scriptblock { cd C:\Repos; ls } 
invoke-command -session $s -scriptblock { param ($repo, $branch) & '.\clone.ps1' -repository $repo -branch $branch} -ArgumentList $repository, $branch

The server script:

param([string]$repository = "repository", [string]$branch = "branch")
git --version
start-process -FilePath git -ArgumentList ("clone", "-b $branch    https://github.com/MyGithub/$repository.git") -Wait 

I've changed the server script to use start process and it is no longer throwing the exception. It creates the new repository directory and the .git directory but doesn't write any of the files from the github repository. This smells like a permissions issue. Once again invoking the script manually (remote desktop into the amazon box and execute it from powershell) works like a charm.

  • Posting your powershell script could help us... – krisFR Jan 8 '14 at 18:28
  • I know I'm late to the party, but if you add -q to the git command "git clone -q github.com.......", the ISE won't show the NativeCommandError if git was successful. If there is truly an error, like the destination path already exists, it will display the error. – Jim Feb 23 '17 at 19:35

As far as Powershell is concerned, it is the correct behaviour.

Unfortunately (at least in my opinon), git outputs a lot of information to stderr even when there isn't any error. For example git checkout -b somenewbranch will output things like modified file lists to stdout but the Switched to new branch somenewbranch message (which I think is the most relevant one) to stderr.

One of the most common ways to deal with this is to redirect stderr output to stdout, e.g:

git rebase master 2>&1

This is enough for most use cases I've seen. If you want to do something with the textual output itself you'll need to go a bit further as Powershell will store the stderr-originating lines as a RemoteException instead of a string. A brief example of how you might deal with something that needs to log output to the console:

$result  = Invoke-Expression "& git checkout -b somefeaturebranch 2>&1"

$output = ""
foreach($line in $result)
    $val = ""
    if($line.GetType().Name -eq "ErrorRecord")
        $val = $line.Exception.Message
        $val = $line
    $output = "$output`r`n$val"

Write-Host $output

I see this 'error' as well when using Powershell ISE and Git locally. It isn't actually an error; rather, Powershell ISE is incorrectly interpreting Git's console output. If you try the console-based Powershell, you should notice that there is no error information displayed. It seems that this is just a peculiarity of Powershell ISE (and possibly other Powershell hosts that don't handle console application output well).

  • Looking back on my answer, I agree with you from a technical standpoint. However, I disagree from an 'end user' perspective. I'll submit a new answer with my findings and potential solutions. Thanks for reminding me of this, @FerretallicA, it got me to learn something new! – nerdshark Nov 7 '15 at 2:50
  • It's not incorrect. git sends a lot of things to stderr even when it's not an error. PS ISE is actually handling it 'correctly', the Powershell console opts for more 'friendly' behaviour by default. – Nathan Chere Nov 7 '15 at 8:12

You may be running into Double Hop problem explained here: http://blogs.msdn.com/b/clustering/archive/2009/06/25/9803001.aspx

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.