FWIW, I always branch off upstream/master. I don't have master synced to my repo, because it just seems like an extra step. Why not go straight to the source? On Oct 31, 2014 11:48 AM, "Eric Snow" <[email protected]> wrote:
> On Fri, Oct 31, 2014 at 2:11 AM, roger peppe <[email protected]> > wrote: > > On 30 October 2014 14:34, Eric Snow <[email protected]> wrote: > >> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe <[email protected]> > wrote: > >>> It's a pity then that if you "go get" a package, origin is the repo > >>> you've branched from. There is always one of those, but you > >>> don't necessary have a fork of the repo yourself. > >> > >> Why wouldn't you want go get to fetch from your clone by default? > > > > What Andrew said. > > > > Also, the only information that "go get" has when a repository > > doesn't exist locally is the home of that repository. > > So when "go get" gets a new package, the only place > > that origin can point to is that repository's home. > > Right. I'm not suggesting that "go get" (or godeps) change the > remotes for a repo that didn't already have a local clone, nor even > for any existing local clones. In fact, I'm saying that the current > behavior of "go get" is just fine. It shouldn't need to worry about > any other remotes than "origin", regardless of if the local clone > already existed. Neither should it worry about where "origin" is > pointing, nor about syncing origin with upstream. > > If someone has pointed "origin" to point to their own remote [1] clone > (which is what the juju CONTRIBUTING doc suggests), then they are > responsible for keeping that synced up with upstream. If they don't > and godeps has issues because it can't find the revision it wants, > that isn't the fault of godeps or "go get". > > I believe the request from earlier (Tim?) is that godeps help out in > that case. [2][3] However, that should not require that "go get" have > any awareness of remotes. > > > > > When starting work on a package, the first thing I will do is > > invariably "go get" that package, which will fetch all new dependencies > > too. For the majority of those dependencies, I won't already > > have forked them on github. If I come to start work on > > one of those dependencies, it will already have an "origin" > > remote pointing to the source of the repo. > > > > So it's much easier IMHO just to go with the flow and keep origin > > always meaning the same thing, whether you've forked the > > repo or not. > > Right. That is fine and should not change, nor need to. It's the > case where you did change your remotes that godeps *could* be more > helpful, regardless of whether or not it's worth doing. > > -eric > > [1] I suppose you could also point "origin" to another repo elsewhere > on your local filesystem. > [2] I was going to pull this conversation into a feature request on > the godeps issue tracker, since it is basically a distraction from the > original thread topic. However, I didn't find any such tracker. The > launchpad project does not seem to have one enabled and there is no > github repo, > [3] Regarding the feature request, here's a possible solution. If the > revision for a repo is not found in "origin" (after running "go get"), > look for it in "upstream" (if that remote exists). If "upstream" > exists but the revision isn't there, give a warning that "upstream" > may be out of date. I suppose godeps could also try fetching from > upstream first (without pushing any changes to upstream). >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
