If you're on an older versison of Git, this might be #26501. But I agree that the errors should be clearer.

#26501 is now closed, but adding some suggestions from that issue that could help future troubleshooting:

Consider extending what gets emitted by -v (#26501 (comment) by @rudis)

I stumbled over the same issue and I found the fact that go doesn't report anything about a failing command troublesome. I needed to use strace to figure out what's going on because even with -v nothing was printed about the failing command.

If possible please also extend -v's output to include for example failing commands to help debugging such issues.

And/or address TODO from modload (#26501 (comment) from @rogpeppe):

I encountered this issue today (I'm using a stock version of Ubuntu 16.04). It's made harder to diagnose by the fact that this TODO from src/cmd/go/internal/modload.go remains unaddressed:

// TODO(rsc): It would be nice to return a specific error encountered
// during the loop above if possible, but it's not clear how to pick
// out the right one.
This means that we don't get to see the actual error encountered (unknown revision refs/tags/v1.0.1) in my case. Even that error isn't ideal when the actual error printed by git is fatal: unrecognised argument: --no-show-signature. Perhaps that output could be shown when using the -v flag?

My git version is 2.7.4.

I just tried one of those git commands and as it happens it does return exit code 1 without printing any error, so perhaps the problem is with git itself. I am using git 2.7.4.

I could move off git 2.7.4 but as it's the default version you get when using Ubuntu 16.04 I think it's important that Go works correctly with that version.

BTW I just tried with a newer version of git (2.18.0) and everything works OK.

I'm not sure what more to do here. I would like to turn off the finding prints by default, although I worry that people will think the go command is just stuck if it's not printing those. But this is very precise:

go: github.com/jmespath/go-jmespath@v0.0.0-20180206201540-c2b33e8439af: git fetch -f --depth=1 origin c2b33e8439af944379acbdd9c3a5fe0bc44bd8a5:refs/dummy in /home/rog/src/go/src/mod/cache/vcs/7b1106ecb177564b0bc9784f963c6c785e31d09dcd9f08114684d32af620443f: exit status 1

It contains enough information to repeat the command, and as you found, something is wrong with that git command. I suppose we could make it say "cd dir && git fetch" instead of "git fetch ... in dir". What's unclear is git here, I think.

Does anyone have any idea what is wrong with git 2.7.4? Does it not support --depth=1?

This is not conclusive, but --depth=<depth> at least shows up in git's Documentation/fetch-options.txt for 2.7.4:

https://github.com/git/git/blob/v2.7.4/Documentation/fetch-options.txt#L10

--depth=<depth>::
	Limit fetching to the specified number of commits from the tip of
	each remote branch history. If fetching to a 'shallow' repository
	created by `git clone` with `--depth=<depth>` option (see
	linkgit:git-clone[1]), deepen or shorten the history to the specified
	number of commits. Tags for the deepened commits are not fetched.

for what its worth git 2.7.4 and go head works fine for me.

➜  httpstat git:(master) ✗ go mod -init -module github.com/davecheney/httpstat
go: creating new go.mod: module github.com/davecheney/httpstat
go: copying requirements from Gopkg.lock
➜  httpstat git:(master) ✗ go build
go: finding github.com/fatih/color v1.5.0
go: finding github.com/mattn/go-isatty v0.0.3
go: finding github.com/mattn/go-colorable v0.0.9
go: finding golang.org/x/text v0.0.0-20170915090833-1cbadb444a80
go: finding golang.org/x/sys v0.0.0-20170922123423-429f518978ab
go: finding golang.org/x/net v0.0.0-20170922011244-0744d001aa84
go: downloading github.com/fatih/color v1.5.0
go: downloading golang.org/x/net v0.0.0-20170922011244-0744d001aa84
go: downloading github.com/mattn/go-colorable v0.0.9
go: downloading github.com/mattn/go-isatty v0.0.3
go: downloading golang.org/x/text v0.0.0-20170915090833-1cbadb444a80
➜  httpstat git:(master) ✗ git --version
git version 2.7.4
➜  httpstat git:(master) ✗ go version
go version devel +e5b1340 Wed Jul 25 23:53:54 2018 +0000 linux/amd64

@rogpeppe can you try running one of the git commands with some of these verbose env vars set

https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems

@gopherbot, please add label help wanted

#25982 (comment) is related here. Whilst as @rsc notes in #26594 (comment) we shouldn't/don't have to log the finding statements, we can log the output in case of error.

This issue #26594 is slightly complicated by the fact that apparently here outputting errors from git would not have helped here (because here git was silent), but it seems outputting errors from git would have helped other issues, e.g., see #26594 (comment)

@thepudds is there any thoughts on when running go in verbose mode running git fetch with one of those verbose flags mentioned in my link? Just thinking about how we can give people the tools they need to debug these issues without filing an issue every time.

https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems

Ok, unless I've missed this above, there appears to be something orthogonal to the git version that is affecting things here, above and beyond any differences in behaviour introduced by the git version itself.

Consider the following as context, which is roughly the state one of my CI builds get into via various Go commands:

cd $(mktemp -d)
git init
git remote add origin https://github.com/neelance/astrewrite

The build was failing because, ultimately, the following git (2.11.0) command failed:

git fetch -f --depth=1 origin 99348263ae862cc230986ce88deaddbf7edcc034:refs/dummy

It fails with exit code 1 and no output to stdout or stderr. A non-zero exit code is fine, but the empty stdout and stderr is not expected (

If I try and reproduce this locally (using the same docker container), I instead get exit code 128 and some error output, specifically the expected output:

docker run -t -i --rm circleci/golang:1.10 bash
cd $(mktemp -d)
git init
git remote add origin https://github.com/neelance/astrewrite
git fetch -f --depth=1 origin 99348263ae862cc230986ce88deaddbf7edcc034:refs/dummy

gives

error: no such remote ref 99348263ae862cc230986ce88deaddbf7edcc034

As far as I can tell, this is exactly the same setup as my CI build; same docker image, git version (2.11.0) etc.

But something is clearly different (I'm probably missing something obvious); I just unable to recreate the environment/scenario in which that git command gives an exit code of 1.

I also can't reproduce the exit code 1 using git 2.7.4:

docker run --rm -i -t ubuntu:16.04 bash
apt-get -y -qq update < /dev/null > /dev/null
apt-get -y -qq install git < /dev/null > /dev/null
cd $(mktemp -d)
git init
git remote add origin https://github.com/neelance/astrewrite
git fetch -f --depth=1 origin 99348263ae862cc230986ce88deaddbf7edcc034:refs/dummy

However, @rogpeppe, with a standard Ubuntu 16.04 setup (git 2.7.4) can reproduce the exit code 1.

At this stage, we're unclear what is different between our environments/setups that causes this difference in behaviour.

Any help/thoughts much appreciated (and apologies if any of this repeats what's gone before, to be honest I'm totally lost at what's going on here).

@mvdan has the answer 🎖

This particular case appears to be affected by the use of an ssh-based git remote.

Using git 2.11.0 (because this particular command is not a problem with more recent git versions) and assuming an appropriate ssh setup:

cd $(mktemp -d)
git init
git remote add origin git@github.com:neelance/astrewrite
git fetch -f --depth=1 origin 99348263ae862cc230986ce88deaddbf7edcc034:refs/dummy

gives exit code 1 and no output.

Using an https-based remote:

cd $(mktemp -d)
git init
git remote add origin https://github.com/neelance/astrewrite
git fetch -f --depth=1 origin 99348263ae862cc230986ce88deaddbf7edcc034:refs/dummy

gives exit code 128 and the following output (which is what we want/need):

error: no such remote ref 99348263ae862cc230986ce88deaddbf7edcc034

I haven't looked into possible solutions, so this is just to note findings so far.

Sorry, another message in this thread

I'm seeing the aforementioned behaviour on CircleCI v2 (which has git 2.11.0), so not an uncommon setup people will be using. CircleCI globally sets url.ssh://git@github.com.insteadof=https://github.com, hence how this comes about.

We fixed this particular error, which was really git's fault.