Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

['Axel Wagner' via golang-nuts]

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.

On Fri, Nov 25, 2016 at 1:27 PM, Mariusz Gronczewski 
wrote:

> 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
>
> 2016-11-25 13:00 GMT+01:00 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.
> >
> >
> > On Fri, Nov 25, 2016 at 12:48 PM, Mariusz Gronczewski  >
> > wrote:
> >>
> >>
> >>
> >> 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
> >>
> >>
> >>>
> >>>
> >>>
> >>> On Fri, Nov 25, 2016 at 11:40 AM, Mariusz Gronczewski <
> xan...@gmail.com>
> >>> wrote:
> 
>  But then go get github.com/me/project will be non-functional ?
> 
>  2016-11-25 11:35 GMT+01:00 Ian Davis :
>  > This is how to do it with a git repository:
>  >
>  >
>  > http://blog.campoy.cat/2014/03/github-and-go-forking-pull-
> 

Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

[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

2016-11-25 13:00 GMT+01:00 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.
>
>
> On Fri, Nov 25, 2016 at 12:48 PM, Mariusz Gronczewski 
> wrote:
>>
>>
>>
>> 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
>>
>>
>>>
>>>
>>>
>>> On Fri, Nov 25, 2016 at 11:40 AM, Mariusz Gronczewski 
>>> wrote:

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

 2016-11-25 11:35 GMT+01:00 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
 >
 >
 > On Fri, Nov 25, 2016, at 10:31 AM, Mariusz Gronczewski wrote:
 >
 > 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"
 > )

Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

['Axel Wagner' via golang-nuts]

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.


On Fri, Nov 25, 2016 at 12:48 PM, Mariusz Gronczewski 
wrote:

>
>
> 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
>
>
>
>>
>>
>> On Fri, Nov 25, 2016 at 11:40 AM, Mariusz Gronczewski 
>> wrote:
>>
>>> But then go get github.com/me/project will be non-functional ?
>>>
>>> 2016-11-25 11:35 GMT+01:00 Ian Davis :
>>> > This is how to do it with a git repository:
>>> >
>>> > http://blog.campoy.cat/2014/03/github-and-go-forking-pull-re
>>> quests-and.html
>>> >
>>> >
>>> > On Fri, Nov 25, 2016, at 10:31 AM, Mariusz Gronczewski wrote:
>>> >
>>> > 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
>>> >
>>> 

Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

[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

 

>
>
> On Fri, Nov 25, 2016 at 11:40 AM, Mariusz Gronczewski  > wrote:
>
>> But then go get github.com/me/project will be non-functional ?
>>
>> 2016-11-25 11:35 GMT+01:00 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
>> >
>> >
>> > On Fri, Nov 25, 2016, at 10:31 AM, Mariusz Gronczewski wrote:
>> >
>> > 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
>> >
>> >
>> > --
>> > 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.
>> >
>> >
>> > --
>> > 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) 
>> 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 .
>> For more 

Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

['Axel Wagner' via golang-nuts]

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.


On Fri, Nov 25, 2016 at 11:40 AM, Mariusz Gronczewski 
wrote:

> But then go get github.com/me/project will be non-functional ?
>
> 2016-11-25 11:35 GMT+01:00 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
> >
> >
> > On Fri, Nov 25, 2016, at 10:31 AM, Mariusz Gronczewski wrote:
> >
> > 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
> >
> >
> > --
> > 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.
> >
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Mariusz Gronczewski (XANi) 
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

[Mariusz Gronczewski]

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

2016-11-25 11:35 GMT+01:00 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
>
>
> On Fri, Nov 25, 2016, at 10:31 AM, Mariusz Gronczewski wrote:
>
> 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
>
>
> --
> 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.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Mariusz Gronczewski (XANi) 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

[Jan Mercl]

On Fri, Nov 25, 2016 at 11:31 AM Mariusz Gronczewski 
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

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

Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

[Sebastien Binet]

On Fri, Nov 25, 2016 at 11:31 AM, Mariusz Gronczewski 
wrote:

> 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" ?
>

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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] So how exactly one does(should do) forking/pull requests in Golang world

[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




On Fri, Nov 25, 2016, at 10:31 AM, Mariusz Gronczewski wrote:

> 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

> 

> 



> --

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


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