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? <div class="gmail_quote">On Oct 31, 2014 11:48 AM, "Eric Snow" <<a href="mailto:eric.snow@canonical.com">eric.snow@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Oct 31, 2014 at 2:11 AM, roger peppe <<a href="mailto:roger.peppe@canonical.com">roger.peppe@canonical.com</a>> wrote: > On 30 October 2014 14:34, Eric Snow <<a href="mailto:eric.snow@canonical.com">eric.snow@canonical.com</a>> wrote: >> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe <<a href="mailto:roger.peppe@canonical.com">roger.peppe@canonical.com</a>> 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). </blockquote></div>