dave / jsgo

GopherJS compiler, serving framework and CDN.
https://jsgo.io/<path>
MIT License
269 stars 11 forks source link

Doesn't work with agamigo.io/material #3

Closed dave closed 6 years ago

dave commented 6 years ago

This should work... Must be a bug in getter.

dave commented 6 years ago

So it looks like there's a difference in behaviour between command line git and go-git. I've opened a go-git ticket:

https://github.com/src-d/go-git/issues/750

dave commented 6 years ago

go get is quite happy to use https://gitlab.com/agamigo/material as the repo root, and command line git can clone that... However, go-git errors:

$ go get -v agamigo.io/material
Fetching https://agamigo.io/material?go-get=1
Parsing meta tags from https://agamigo.io/material?go-get=1 (status code 200)
get "agamigo.io/material": found meta tag get.metaImport{Prefix:"agamigo.io/material", VCS:"git", RepoRoot:"https://gitlab.com/agamigo/material"} at https://agamigo.io/material?go-get=1
agamigo.io/material (download)
agamigo.io/material
$ git clone https://gitlab.com/agamigo/material
Cloning into 'material'...
warning: redirecting to https://gitlab.com/agamigo/material.git/
remote: Counting objects: 1016, done.
remote: Compressing objects: 100% (559/559), done.
remote: Total 1016 (delta 504), reused 679 (delta 306)
Receiving objects: 100% (1016/1016), 216.49 KiB | 564.00 KiB/s, done.
Resolving deltas: 100% (504/504), done.
func TestClone(t *testing.T) {
    _, err := git.Clone(memory.NewStorage(), memfs.New(), &git.CloneOptions{
        URL:               "https://gitlab.com/agamigo/material",
        SingleBranch:      true,
        Depth:             1,
        RecurseSubmodules: git.DefaultSubmoduleRecursionDepth,
    })
    if err != nil {
        t.Fatal(err)
    }
}

Output:

getter_test.go:23: repository not found
dave commented 6 years ago

I suspect it's connected with: warning: redirecting to https://gitlab.com/agamigo/material.git/

dave commented 6 years ago

Hey @bzub I think this is yours? It looks like there's a bug in go-git (or perhaps intentional deviation from the behaviour of the git command line tool)...

However, while we wait for that to be fixed, you can fix it by making a change to your vanity package path response:

This is your response:

$ curl "https://agamigo.io/material/?go-get=1"
<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
        <meta name="go-import"
            content="agamigo.io/material git https://gitlab.com/agamigo/material">
        <meta http-equiv="refresh"
            content="0; url=https://gitlab.com/agamigo/material">
    </head>
    <body>
        Nothing to see here; <a href="https://gitlab.com/agamigo/material">move along</a>.
    </body>
</html>

It's instructing us to use https://gitlab.com/agamigo/material at the repo root... That works in the git command line tool (with a redirect), but fails with go-git.

If we ask gitlab.com for the repo root corresponding to gitlab.com/agamigo/material, we get this:

$ curl "https://gitlab.com/agamigo/material?go-get=1"
<html><head><meta name="go-import" content="gitlab.com/agamigo/material git https://gitlab.com/agamigo/material.git" /></head></html>

It responds with https://gitlab.com/agamigo/material.git, which is the correct repo root that git and go-git can both fetch without any problems.

I'll continue looking for a better solution to this... It would be ideal if git and go-git were identical. I'll leave this ticket open to track the problem.

bzub commented 6 years ago

I've updated my go-import meta tags and it's working as expected. Thanks for looking into this @dave!

It could be that I'm just using the git fetch URL incorrectly, and that the git command is allowing it for convenience. Maybe a little documentation/error message in jsgo is all that's needed to point users having the same issue in the right direction.

dave commented 6 years ago

It's ok - looks like the go-git people are keen to work the same as git... They have a PR for this bug now: https://github.com/src-d/go-git/pull/751

dave commented 6 years ago

Bug fixed in go-git!