Same here, using it like this:

getter.Get("./skills", "git::https://bitbucket.org/edwin_luijten/q_skills.git") // does not work
getter.Get("./skills", "https://bitbucket.org/edwin_luijten/q_skills.git") // also does not work

Results in: /usr/bin/git exited with 128: fatal: not a git repository (or any of the parent directories): .git

I'm not able to reproduce this. I ran your exact command.

Exit code 128 usually means git can't be found on the PATH.

Do you have any more info to share? Can't repro for now.

Hi @mitchellh,

I'm testing go-getter and faced the same issue. From what I could find, that error is returned from the Git client because the destination directory is not a (local) Git repository.
If you initialize it (git init) and try to run go-getter again, you get the following error:

/usr/bin/git exited with 1: error: pathspec 'master' did not match any file(s) known to git.

I'm running this on OSX Mojave with Git v2.17.2

I hope this helps.

Best,
Nahuel

This seems to be because the code tries to update the local git repo if the destination directory exists. If you pass a non-existent directory to Get() then it should work.

See here:

Just to recap, since I ran into this myself: mkdir dest; go-getter github.com/hashicorp/go-getter ./dest (or go-getter github.com/hashicorp/go-getter .) fails with a rather inscrutable error message
But if ./dest does not exist then it works

It feels like either the behavior should be patched or a better error message should be returned here.

Just to recap, since I ran into this myself: mkdir dest; go-getter github.com/hashicorp/go-getter ./dest (or go-getter github.com/hashicorp/go-getter .) fails with a rather inscrutable error message
But if ./dest does not exist then it works

It feels like either the behavior should be patched or a better error message should be returned here.

Huge lifesaver. I couldn't figure out why it was error out and giving the 128 error. I deleted the dst folder and sure enough it worked.

I don't know what specifically has changed but in running my own tests, it seems that now on osx, it will fail silently. No error is reported and the destination directory is left empty.

git version 2.29.2
github.com/hashicorp/go-getter v1.5.2

I have run into the same error but from inside my own code, which pretty much does the same as mentioned before.
It creates a directory and then downloads the files into it.

dst, err := ioutil.TempDir("", "jobdir")
if err != nil {
  return nil, err
}
defer os.Remove(dst)

client = &gg.Client{
  Mode: gg.ClientModeDir,
  Src:  jpath,
  Pwd:  pwd,
  Dst:  dst,
}

err = client.Get()
if err != nil {
  return nil, err
}

In my case when using git::https://github.com/eveld/nomad-multiple-files.git it results in

But when using git::https://github.com/eveld/nomad-multiple-files.git//test it succeeds.

just change https to git
git clone git://github.com/user/repo solve my problem

I am unable to clone the private repo inside the pod.

Warning CannotConnectToProvider 3m33s (x21 over 75m) managed/workspace.tf.crossplane.io (combined from similar events): cannot get remote Terraform module: error downloading 'https://github.devtools.predix.io/industrial-cloud-pcs/cp-aws.git?ref=main': /usr/bin/git exited with 128: Cloning into '/tmp/getter992332245/temp'...
fatal: unable to access 'https://github.devtools.predix.io/industrial-cloud-pcs/cp-aws.git/': Failed to connect to github.devtools.predix.io port 443: Operation timed out

Any idea on how to do that ?

If you are reading this, I was trying to clone into an existing directory and it was failing, cloning into a new directory resolved it (thanks to #114 (comment))

Just stumbled on this while investigating an issue and it looks like this was fixed as a side-effect of #497, released in v1.7.5.

mkdir dest; go-getter "github.com/hashicorp/go-getter?ref=v1.7.5" ./dest now works 🎉

Thanks for noticing this @arththebird, on git update v1.7.5 now removes and reinitializes the git config within the destination which should resolve this issue as well as other security related ones.

Please feel free to ping me in case you notice something going wrong following this change.

Since #497 seems to have fixed the issue, I'll go ahead and close this.
Please re-open or comment in case the issue persists.