On 31 October 2014 15:48, Eric Snow <eric.s...@canonical.com> wrote: > On Fri, Oct 31, 2014 at 2:11 AM, roger peppe <roger.pe...@canonical.com> > wrote: >> On 30 October 2014 14:34, Eric Snow <eric.s...@canonical.com> wrote: >>> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe <roger.pe...@canonical.com> >>> 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.
I don't see how I could do that. To pull from a different remote, godeps would presumably have to name that remote (i.e. "be aware" of it). > [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, That's a good point. I hadn't realised that it was necessary to enable bug tracking explicitly in launchpad. That's done now - feel free to report bugs. > [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). I guess it could always try to fetch all configured remotes (perhaps concurrently) if the initial godeps fetch fails. That has the potential disadvantage that some remotes might be badly configured and hang up though. Probably easier just to make sure that your default upstream is configured correctly. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
