You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
quietly switch submodule url for all libs fetched from gopkg.in.
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]>
0 commit comments