Open parsadotsh opened 5 years ago
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: https://github.com/hashicorp/go-getter/blob/9363991638334fdee4f649819138250a3b6402c8/get_git.go#L113
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
(orgo-getter github.com/hashicorp/go-getter .
) fails with a rather inscrutable error message But if./dest
does not exist then it worksIt 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 https://github.com/hashicorp/go-getter/issues/114#issuecomment-469262528)
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.
All of these give the same error:
This also occurs on nomad. What is the problem? I'm using the latest version.