Skip to content
This repository was archived by the owner on Sep 11, 2020. It is now read-only.

Checking out over https fails #623

Closed
dsvensson opened this issue Oct 21, 2017 · 1 comment
Closed

Checking out over https fails #623

dsvensson opened this issue Oct 21, 2017 · 1 comment
Labels

Comments

@dsvensson
Copy link

When trying to checkout https://gopkg.in/yaml.v2

I get the following error message:
pkt-line 3: invalid capabilities: arguments not allowed (symref=HEAD:refs/heads/v2 multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed no-done oldref=HEAD:refs/heads/v2 agent=git/github-g09a9ed6d3a)

The following code is used:

storer := memory.NewStorage()
repo, err := git.Clone(storer, nil, &git.CloneOptions{URL: "https://gopkg.in/yaml.v2"})
if err != nil {
    fmt.Println(err)
}
@orirawlings
Copy link
Contributor

I suspect this is due to a bug in the validation code for capabilities (see (*capability.List).validate). Basically if an capability option isn't recognized, the code automatically assumes that it shouldn't allow arguments. I think in this case, go-git isn't familiar with the oldref option, and produces and error on the unexpected argument.

I'll work on a patch.

orirawlings added a commit to orirawlings/go-git that referenced this issue Oct 23, 2017
warpfork added a commit to polydawn/rio that referenced this issue Dec 13, 2017
gopkg.in is... a cute idea.  If you don't have any other version control.

If you *DO* have version control -- say, a nice thing like git submodules --
then that site just gets in your way *massively*.

In a particular strike of irony, what brings this to my attention is that
I want a bugfix in go-git which is several months old:
src-d/go-git#623

The joke is... this bug regards go-git's handing of *gopkg.in*.

And I can't fetch it because of... gopkg.in.
(Even going into our submodule and directly fetching and explicitly
asking for `git checkout origin/master` *doesn't work* because
gopkg.in works by *lying* about what git master *is*.  Whee.)

Ke ke ke.

So.  We can't *not* have the gopkg.in paths in our gopath, because
go-git internally references their own packages with that path
(I've commented before that I think this is a mistake in another issue:
src-d/go-git#76 ... but whatever, moving on);
go imports just don't work like that.

But we *can* tell git submodules to fetch from somewhere else.

And this will actually work fine.
Chalk up another point scored for git submodules -- complex? sure;
but dang if they don't get the job done, even in an *incredible*
variety of complex situations.

I'm splitting the actual library updates into a separate commit
(it'll be noisy -- guess why.  They changed the version of some
of their other libraries, so we actually get to see *new paths*
from gopkg.in.  Fun!).

Signed-off-by: Eric Myhre <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants