Aha! Okay, one good workaround for me is adding export-ignore to the .gitattribtues and abandoning the .lfsconfig. I still find the default behavior a bit strange though.
Also I was probably misinterpreting why --worktree-attributes was working after reading the docs further. On Wednesday, October 3, 2018 at 1:20:27 PM UTC-4, alexander...@gmail.com wrote: > > Hi there, > > Hoping someone here has a good workaround. Used godep w/ vendor in the > past, so this new ground for me. > > tl;dr > Can I pass the git archive flag --worktree-attributes to go mod commands > or go get? > > ### What version of Go are you using (`go version`)? > > go version go1.11 darwin/amd64 > > ### Does this issue reproduce with the latest release? > > Yes > > ### What operating system and processor architecture are you using (`go > env`)? > > GOARCH="amd64" > GOBIN="" > GOCACHE="/Users/alexbarry/Library/Caches/go-build" > GOEXE="" > GOFLAGS="" > GOHOSTARCH="amd64" > GOHOSTOS="darwin" > GOOS="darwin" > GOPATH="/Users/alexbarry/go" > GOPROXY="" > GORACE="" > GOROOT="/usr/local/Cellar/go/1.11/libexec" > GOTMPDIR="" > GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64" > GCCGO="gccgo" > CC="clang" > CXX="clang++" > CGO_ENABLED="1" > GOMOD="" > CGO_CFLAGS="-g -O2" > CGO_CPPFLAGS="" > CGO_CXXFLAGS="-g -O2" > CGO_FFLAGS="-g -O2" > CGO_LDFLAGS="-g -O2" > PKG_CONFIG="pkg-config" > GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments > -fmessage-length=0 > -fdebug-prefix-map=/var/folders/cd/2sl0rxtn7y9bvdgyj8z7w6c80000gp/T/go-build922194055=/tmp/go-build > > -gno-record-gcc-switches -fno-common" > > ### What did you do? > > I'm using go modules and trying to import a repo that uses git-lfs to > handle large binary files. I have a .lfsconfig file in the root of the repo > with fetchexclude = * to avoid pulling the large files on clone. It works > fine with a regular git clone or fetch, the files are not downloaded. > However, when I try to import packages from this go module into another go > module in another repo and go build, there are several issues. > > ### What did you expect to see? > > I expected go build to download the packages and build successfully. > > ### What did you see instead? > > - go build downloads everything, but reports* unknown import path > "bitbucket.org/xxx/yyy/zzz <http://bitbucket.org/xxx/yyy/zzz>": module > source tree too big* > - go mod tidy reports > * go build bitbucket.org/xxx/yyy/zzz <http://bitbucket.org/xxx/yyy/zzz>: > no Go files in * > - go get reports the same as go mod tidy > > If I setup my ~/.gitconfig with lfs.fetchexclude=* and clean out my > modcache, I am able to build fine. This isn't ideal though as it will break > other lfs setups for my team, and will cause some CI issues. > > I've run go get -x and repeated the same git steps that the go command was > using. It works fine through the fetch, but the problem seems to be with *git > archive*. Here, the large files are downloaded and my .lfsconfig is > ignored. When go performs this, it then hits me with the 500MB max size > cap, which is a bit of a shame since git already downloaded everything, and > the whole reason I set up lfs in the first place was to get around this > cap. I'd expect go get to behave similarly to my git clone or fetch. Is > there a reason we need this zip step just to unzip it anyway? > > If I pass the --worktree-attributes flag to git archive, it honors my > .lfsconfig and skips the downloads. The resulting zip is small. > > So my question is, is there a way to pass the --worktree-attributes flag > through the go mod commands or go get? I took a look at > cmd/go/internal/modfetch/codehost/git.go, but it didn't seem like it. > > Any help much appreciated. > > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.