Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
dave opened this issue Feb 14, 2018 · 7 comments
Closed

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

dave opened this issue Feb 14, 2018 · 7 comments

Comments

@dave
Copy link
Owner

dave commented Feb 14, 2018

This should work... Must be a bug in getter.
@dave
Copy link
Owner Author

dave commented Feb 14, 2018

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

src-d/go-git#750

@dave
Copy link
Owner Author

dave commented Feb 14, 2018

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
Copy link
Owner Author

dave commented Feb 14, 2018

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

@dave
Copy link
Owner Author

dave commented Feb 14, 2018

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
Copy link

bzub commented Feb 15, 2018

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
Copy link
Owner Author

dave commented Feb 15, 2018

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: src-d/go-git#751

@dave
Copy link
Owner Author

dave commented Feb 18, 2018

Bug fixed in go-git!

@dave dave closed this as completed Feb 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dave @bzub