TLDR > Is it possible to fork a repo and change the import path of the repository?
Not in one step with the github “click to fork”. You need to do one of the following: 1. Create a new empty remote repo, remap imports, and push to the new remote. 2. Fork, update imports, push. 3. Assuming vanity URL is used, fork and then update the vanity urls meta tag. > Is it possible to have: > both repos yes but I would try to deprecate one as “archived/historical”. > every repo with it's own import path yes, it does by nature of being different urls > code exchange between them yes, but I’d avoid if possible. You’ll need to remap imports to match the repo so it’s not a simple push to both remotes. — You can use gofmt to remap the import paths. If you’re aim is to “sync” repos (I’m not clear why you’d want this aside from a clearance process for making corp stuff public) then you could encode the commands in a script or make target and trigger them as part of a “publishing process”. Relative import paths were available at one point but they are now deprecated/unavailable. In theory it allowed ignorance of the SCMs root at the sacrifice of not being go gettable and probably a number of other issues which resulted in its removal. Godoc isn’t essential infrastructure in my opinion, you can serve docs locally in a pinch and I often do this while working offline in planes, trains, and automobiles. Introducing a registry however adds a failure domain/security concern that can break or be compromised. If githubs down and your repo is on github it’s the same failure domain so you’re arguably no worse/better off if your deps are there. Committing vendor where possible minimises the failure domains further and generally yields faster CI builds as a side benefit IME. Another option might be abusing vanity urls if the objective is to support ongoing development in both repos (eg returning different meta tags based on a work IP vs not or a local /etc/hosts override to a different vanity url host). I’m not terribly familiar with them but in theory it should allow the same import path in both repos but it would likely result in some confusing issues. I don’t think it’s a great idea but it might work for your scenario. On Fri, Dec 28, 2018 at 18:24, Sotirios Mantziaris <smantzia...@gmail.com> wrote: > If i understand it correctly the proposed solutions does not solve the > problem of forking repos. > The ideal solution would be to have a import path agnostic of the repo > location so that a fork could be up and downstream compatible. > > On Thursday, December 13, 2018 at 12:32:11 AM UTC+2, Ian Lance Taylor > wrote: > >> On Wed, Dec 12, 2018 at 8:08 AM Robert Engels <ren...@ix.netcom.com> >> wrote: >> > >> > I am pretty sure that the correct solution is to decouple the package >> from its location. And a global Go registry can tell Go get where that >> package can currently be found. >> >> You don't need a global registry. Or, rather, the global registry can >> be DNS. You can set up your own trivial redirector, using a meta tag, >> as discussed at https://golang.org/cmd/go/#hdr-Remote_import_paths . >> Or you can use an existing general purpose redirector such as >> gopkg.in. Either way you can enforce this with an import comment as >> discussed at https://golang.org/cmd/go/#hdr-Import_path_checking . >> >> Ian >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- - sent from my mobile -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
