So how exactly one does(should do) forking/pull requests in Golang world

[Mariusz Gronczewski]

Hi,

So let's say there is a project, living under path github.com/local/project. Project is neatly divided into a bunch of packages and uses recommended absolute paths:

package main

import (

"github.com/external/dep1"

"github.com/local/project/config"

"github.com/local/project/backend"

"github.com/local/project/frontend"

)

and packages inside of it also use that:

package backend

import (

"github.com/external/dep3"

"github.com/external/dep4"

"github.com/local/project/config"

"github.com/local/project/backend/nosql"

"github.com/local/project/backend/sql"

"github.com/local/project/backend/dummy"

)

package frontend

import (

"github.com/external/dep5"

"github.com/external/dep6"

"github.com/local/project/config"

"github.com/local/project/backend"

"github.com/local/project/frontend/html"

"github.com/local/project/frontend/pdf"

)

...how does one contribute to it ?

If I just go and fork it and do a bunch of changes across packages then I can't test it because everything will be under "github.com/me/project" so deps will come from the "wrong" place.

If I go and find-replace everything now I can work in peace but any diff or pull request from it wont make any sense as now it will contain wrong paths

If I use relative packages then things like `go test` complain about local imports and wont run.

Surely there is a better method than "just glue it with some symlinks" ?

Cheers, Mariusz

[Ian Davis]

This is how to do it with a git repository:

http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html

--

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.

For more options, visit https://groups.google.com/d/optout.

[Sebastien Binet]

you fork it.

then, in your $GOPATH:

cd $GOPATH/src/github.com/local/project

git remote add me g...@github.com:me/project

git checkout -b new-pr

$EDITOR something.go

go get ./...

go test ./...

git commit -m "project: something got changed"

git push me new-pr

and voila.

hth,

-s

Cheers, Mariusz

--
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+unsubscribe@googlegroups.com.

[Jan Mercl]

On Fri, Nov 25, 2016 at 11:31 AM Mariusz Gronczewski <xan...@gmail.com> wrote:

> If I just go and fork it and do a bunch of changes across packages then I can't test it because everything will be under "github.com/me/project" so deps will come from the "wrong" place.

1. Fork it on githug.

2. $ mkdir -p $GOPATH/src/github.com/local/project

3. $ cd $GOPATH/src/github.com/local

4. $ git clone https://github.com/me/project

--

-j

[Mariusz Gronczewski]

But then go get github.com/me/project will be non-functional ?

> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/if5H8kRAT30/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Mariusz Gronczewski (XANi) <xan...@gmail.com>
GnuPG: 0xEA8ACE64

[Axel Wagner]

It is pretty simple:

* If you actually *fork* a project (not what github calls a "fork", but "create a repo with a different set of maintainers"), *that is a different package*. It will contain different code and have a different mantainer. So it is a feature, that go get won't work on it OOTB. To make it work, you have to commit making and using it as a different package by changing import paths. People pretend like forking should take over another persons package, but that just doesn't make sense, that's the whole point of identifying packages by import paths and having a discovery mechanism that reconciles conflicts by relying on the DNS.

* To prepare a PR, just add your "fork" (I hate githubs nomenclature here) as a second remote in $GOPATH/src/github.com/upstream/project. Commit and push to your fork, then create the PR. When done, optionally, delete your fork.

The two things are very different processes. One is "being dissatisfied with a project so taking over maintainership" (what the FOSS-community calls "forking") and the other is "publishing a copy of a repo with your patches so that the maintainer can pull from it" (what github calls "forking", but is actually just "using the decentralized nature of git as a VCS). Don't mix the two up and everything makes sense.

> email to golang-nuts+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --

> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/if5H8kRAT30/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> golang-nuts+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.



--

Mariusz Gronczewski (XANi) <xan...@gmail.com>
GnuPG: 0xEA8ACE64

--
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+unsubscribe@googlegroups.com.

[Mariusz Gronczewski]

On Friday, November 25, 2016 at 12:10:56 PM UTC+1, Axel Wagner wrote:

It is pretty simple:

* If you actually *fork* a project (not what github calls a "fork", but "create a repo with a different set of maintainers"), *that is a different package*. It will contain different code and have a different mantainer. So it is a feature, that go get won't work on it OOTB. To make it work, you have to commit making and using it as a different package by changing import paths. People pretend like forking should take over another persons package, but that just doesn't make sense, that's the whole point of identifying packages by import paths and having a discovery mechanism that reconciles conflicts by relying on the DNS.

* To prepare a PR, just add your "fork" (I hate githubs nomenclature here) as a second remote in $GOPATH/src/github.com/upstream/project. Commit and push to your fork, then create the PR. When done, optionally, delete your fork.

The two things are very different processes. One is "being dissatisfied with a project so taking over maintainership" (what the FOSS-community calls "forking") and the other is "publishing a copy of a repo with your patches so that the maintainer can pull from it" (what github calls "forking", but is actually just "using the decentralized nature of git as a VCS). Don't mix the two up and everything makes sense.

I get it but often I have a problem where "main" place of development is our internal repository (and for various political reasons github can't be used for that) but we'd still want to open source that code and not have to deal with path translation.

There is also the "I want to show it to someone but they are git-illiterate" case

 

> email to golang-nuts...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --

> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/if5H8kRAT30/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> golang-nuts...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.



--

Mariusz Gronczewski (XANi) <xan...@gmail.com>
GnuPG: 0xEA8ACE64

--
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.

[Axel Wagner]

I think it's reasonable to expect you to set up your GOPATH accordingly, if you want the layout to be internal and specific and deviating from the discovery mechanism. There is no reason, why a tool couldn't fetch your internal git-repository to the subpath of $GOPATH that corresponds to your public mirror.

I also advocated elsewhere for go get having the ability to use some kind of mirror for fetching, to solve the "code can vanish" objection why people want vendoring (e.g. your company runs a mirror of all your used open source code and you use "go get --proxy=internal.company.net github.com/some/package" and go-get fetches it from "internal.company.net/github.com/some/package" or something like that).

In any case, I don't think that these things are outweighing the pros of go's decentralized approach to namespacing and hosting; the disadvantages have relatively obvious solutions.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Mariusz Gronczewski]

I'm fine with namespacing and I see benefits for it for deps, just it
would be nice to have something inbetween absolute path and
"../../something" (like "$ROOT/packagename") for package-local
"subpackages" that are not designed to be standalone ones (like in my
case it is usually a package holding few structs shared between other
packages).

> I also advocated elsewhere for go get having the ability to use some kind of mirror for fetching, to solve the "code can vanish" objection why people want vendoring (e.g. your company runs a mirror of all your used open source code and you use "go get --proxy=internal.company.net github.com/some/package" and go-get fetches it from "internal.company.net/github.com/some/package" or something like that).

Yeah it would be nice. Maybe in the form of .dotfile with just a list
of aliases for each part of the address, grouped into "profiles". That
would allow to for example have a empty profile (or just one that maps
your public code to github and leaves private for internal repos) for
normal work and "github-down" profile that points it to internal
mirror in case there is something wrong with

>> email to golang-nuts...@googlegroups.com.

[Axel Wagner]

There is exactly one instance of "package local sub-packages" and that is internal packages (okay. And arguably vendoring). For everything else, the same logic applies. I don't find it too much to ask in that case, to actually and explicitly fork.

>> email to golang-nuts+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>