On 30 October 2014 09:47, Nate Finch <nate.fi...@canonical.com> wrote: > Upstream and origin are very very common in the git world. Most any how to > or stack overflow answer uses those by default. Origin is your repo and > upstream is the repo you branched from. I started out doing it your way, > Roger, since I agree that information does flow both ways, and naming my > repo after myself made sense, but I got so annoyed with every answer I > looked up using origin and upstream that I changed to just use those terms. > > Using standard terms is a good thing so we all know what we're talking > about.
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. Hence I think that it's worth reconsidering this for our Go-centric world. It's good to have things work correctly by default. Also, as I said, godeps doesn't have any special preference for upstream or origin - it just does a git fetch. It's interesting to read in the comments on the top answer in this SO question: http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github : "It is worth mentioning in context of github it makes more sense to have origin be the master-repo and use github username as the remote name for your and other forks. Tools like defunkt.io/hub does this and makes working with repositories and collaborating across forks much more uniform." So I'm not the only one that feels this way. > On Oct 30, 2014 4:22 AM, "roger peppe" <roger.pe...@canonical.com> wrote: >> >> On 29 October 2014 21:03, Tim Penhey <tim.pen...@canonical.com> wrote: >> > On 30/10/14 01:11, roger peppe wrote: >> >> A better solution here, which I've been meaning to do for a while, >> >> would be to change godeps so that it can explore all possible >> >> targets. I had a go at that this morning (just adding all tags to >> >> build.Context) but it's not quite as easy as that. I should >> >> be able to fix it soon though. >> > >> > While you are looking at godeps, I don't suppose you can fix it so it >> > looks for the upstream remote? >> >> As things currently are, godeps doesn't know about any remote >> in particular, and I think that's probably correct - it just uses >> "git fetch" (with no arguments) to fetch, and relies on the >> defaults for that. >> >> > I was told that we should have the origin remote being our personal >> > github repo and upstream being the team repo. >> >> I actually think that this is not a great way to configure things. >> When you clone a git repository (for example by doing "go get") >> there is only one remote configured, and that's "origin". >> >> So if I changed godeps to pull from upstream, it would have to >> fall back to pulling from origin in this, the most common case. >> >> Personally, I find the very word "upstream" confusing when >> used in this area - information flows both ways. The >> one certainty is that everything is destined for the >> main repo, so naming that "origin" makes sense to me. >> >> I never create a repo named "upstream" - I have "origin" >> and I name other remotes after github users, e.g. "rogpeppe", >> which seems to scale better when I'm collaborating with >> other people. >> >> > When godeps tries to pull in new revisions into a repo where I have the >> > remotes set as I was told to, godeps fails to pull in new revisions and >> > I normally do something like: >> > >> > (cd ../names && git fetch upstream master) >> > >> > Then run the godeps command again. >> >> All the above said, I don't think there's anything stopping you from using >> this. Just do: >> >> git branch --set-upstream-to upstream/master >> >> and I think it should work (though I haven't actually tried it) >> >> cheers, >> rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
