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.

Reply via email to