Comments on: Forking Golang repositories on GitHub and managing the import path

By: Dan Tenenbaum

Dan Tenenbaum — Thu, 07 Dec 2017 23:35:00 +0000

You say “The source code’s import path fits your directory layout now, but as you push/pull you are only speaking to your own awesome-you repository.”

But what about when you “go get ./…”? Or when the compiler tries to resolve dependencies? Are you then speaking to the original repository? Seems like then it might pull from the original when that is not what you want.

By: Alexandre Richonnier

Alexandre Richonnier — Wed, 18 Oct 2017 07:48:00 +0000

Hi, Thanks for the useful blog entry.
To automate this process, I wrote a small script. You can find more details on my blog http://www.hera.cc/2017/10/go-get-and-fork-script-helper-workaround/ …

By: darrenrush

darrenrush — Fri, 25 Aug 2017 17:59:00 +0000

Any reason you didn’t submit this as an Issue to the main go repository? I would go so far as to say this is bug with security and social implications. The additional friction this adds to the fork/PR/merge workflow means that the amount of collaboration from open source and other contributors is greatly limited for Go relative to just about every other language.

By: Joakim Söderberg

Joakim Söderberg — Mon, 18 Jul 2016 16:03:24 +0000

Thanks for the useful blog entry. I am learning Go and found an improvement in a depedency, when I ran into this exact issue.

I had initially thought the fact that you can simply do an import on a github project like this is a really cool feature in golang…

However, after running into this issue, and then realising there is no “official” or “good” solution for this, I kind of think it’s a bad design decision. My 1 line “fix” I wanted to test now becomes a lot bigger hassle. Especially when I am building and running my go-app within a docker. Simply going in and changing the git clone and similar solutions will be very “unclean” and cumbersome.