I will try some of the suggestion in this topic to see what works out. I will open a feature request in the golang repo for forking support.
On Saturday, December 29, 2018 at 6:56:32 AM UTC+2, Nathan Fisher wrote: > > 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 <smant...@gmail.com > <javascript:>> 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...@googlegroups.com <javascript:>. >> 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.
