<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 10, 2014 at 6:02 AM, Tim Penhey <span dir="ltr"><<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'm more interested in a solution that works for everyone rather than<br> pointing fingers.<br> <br> Given that our current docs suggest specifying origin to personal repo,<br> and upstream to the juju ones, is there any way we can configure the<br> local repo such that when we say 'git fetch' it fetches from upstream<br> rather than origin?<br></blockquote><div><br></div><div>From "git help fetch":</div><div><br></div><div><div> "When no remote is specified, by default the origin remote will be used,</div><div> unless there’s an upstream branch configured for the current branch."</div></div><div><br></div><div>The only times I've had trouble with "godeps -u" is when I've not set the upstream branch correctly. Here's how you can do that:</div><div><br></div><div>$ # initially no upstream set</div><div><div>$ git fetch -v</div><div>From github.com:axw/juju</div></div><div>(noise)</div><div><br></div><div><div>$ git branch -vv | grep \*</div></div><div>* icantbelieveitsnotmaster fc54097 Merge pull request #1070 from axw/lp1362072-azure-verify-credentials</div><div><div>$ git remote -v</div><div>origin<span class="" style="white-space:pre"> </span>git@github.com:axw/juju.git (fetch)</div><div>origin<span class="" style="white-space:pre"> </span>git@github.com:axw/juju.git (push)</div><div>upstream<span class="" style="white-space:pre"> </span>git@github.com:juju/juju.git (fetch)</div><div>upstream<span class="" style="white-space:pre"> </span>no-pushing (push)</div></div><div><div>$ git branch --set-upstream-to upstream/master</div><div>Branch icantbelieveitsnotmaster set up to track remote branch master from upstream.</div></div><div><div>$ git branch -vv | grep \*</div><div>* icantbelieveitsnotmaster fc54097 [upstream/master] Merge pull request #1070 from axw/lp1362072-azure-verify-credentials</div></div><div> </div><div>$ # git fetch will now go to the right place</div><div><div>$ git fetch -v</div><div>(noise)</div><div>From github.com:juju/juju</div><div>(noise)</div></div><div><br></div><div>Cheers,</div><div>Andrew</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Failing that, I'd suggest that we change our docs so we don't break our<br> contributors.<br> <br> The problem is that right now, someone following our docs will get a<br> broken experience.<br> <span class=""><font color="#888888"><br> Tim<br> </font></span><div class=""><div class="h5"><br> On 30/10/14 23:40, roger peppe wrote:<br> > On 30 October 2014 09:47, Nate Finch <<a href="mailto:nate.finch@canonical.com">nate.finch@canonical.com</a>> wrote:<br> >> Upstream and origin are very very common in the git world. Most any how to<br> >> or stack overflow answer uses those by default. Origin is your repo and<br> >> upstream is the repo you branched from. I started out doing it your way,<br> >> Roger, since I agree that information does flow both ways, and naming my<br> >> repo after myself made sense, but I got so annoyed with every answer I<br> >> looked up using origin and upstream that I changed to just use those terms.<br> >><br> >> Using standard terms is a good thing so we all know what we're talking<br> >> about.<br> ><br> > It's a pity then that if you "go get" a package, origin is the repo<br> > you've branched from. There is always one of those, but you<br> > don't necessary have a fork of the repo yourself.<br> ><br> > Hence I think that it's worth reconsidering this for our Go-centric world.<br> > It's good to have things work correctly by default.<br> ><br> > Also, as I said, godeps doesn't have any special preference for<br> > upstream or origin - it just does a git fetch.<br> ><br> > It's interesting to read in the comments on the top answer<br> > in this SO question:<br> > <a href="http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github" target="_blank">http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github</a><br> > :<br> ><br> > "It is worth mentioning in context of github it makes more sense to<br> > have origin be the master-repo and use github username as the remote<br> > name for your and other forks. Tools like <a href="http://defunkt.io/hub" target="_blank">defunkt.io/hub</a> does this and<br> > makes working with repositories and collaborating across forks much<br> > more uniform."<br> ><br> > So I'm not the only one that feels this way.<br> ><br> >> On Oct 30, 2014 4:22 AM, "roger peppe" <<a href="mailto:roger.peppe@canonical.com">roger.peppe@canonical.com</a>> wrote:<br> >>><br> >>> On 29 October 2014 21:03, Tim Penhey <<a href="mailto:tim.penhey@canonical.com">tim.penhey@canonical.com</a>> wrote:<br> >>>> On 30/10/14 01:11, roger peppe wrote:<br> >>>>> A better solution here, which I've been meaning to do for a while,<br> >>>>> would be to change godeps so that it can explore all possible<br> >>>>> targets. I had a go at that this morning (just adding all tags to<br> >>>>> build.Context) but it's not quite as easy as that. I should<br> >>>>> be able to fix it soon though.<br> >>>><br> >>>> While you are looking at godeps, I don't suppose you can fix it so it<br> >>>> looks for the upstream remote?<br> >>><br> >>> As things currently are, godeps doesn't know about any remote<br> >>> in particular, and I think that's probably correct - it just uses<br> >>> "git fetch" (with no arguments) to fetch, and relies on the<br> >>> defaults for that.<br> >>><br> >>>> I was told that we should have the origin remote being our personal<br> >>>> github repo and upstream being the team repo.<br> >>><br> >>> I actually think that this is not a great way to configure things.<br> >>> When you clone a git repository (for example by doing "go get")<br> >>> there is only one remote configured, and that's "origin".<br> >>><br> >>> So if I changed godeps to pull from upstream, it would have to<br> >>> fall back to pulling from origin in this, the most common case.<br> >>><br> >>> Personally, I find the very word "upstream" confusing when<br> >>> used in this area - information flows both ways. The<br> >>> one certainty is that everything is destined for the<br> >>> main repo, so naming that "origin" makes sense to me.<br> >>><br> >>> I never create a repo named "upstream" - I have "origin"<br> >>> and I name other remotes after github users, e.g. "rogpeppe",<br> >>> which seems to scale better when I'm collaborating with<br> >>> other people.<br> >>><br> >>>> When godeps tries to pull in new revisions into a repo where I have the<br> >>>> remotes set as I was told to, godeps fails to pull in new revisions and<br> >>>> I normally do something like:<br> >>>><br> >>>> (cd ../names && git fetch upstream master)<br> >>>><br> >>>> Then run the godeps command again.<br> >>><br> >>> All the above said, I don't think there's anything stopping you from using<br> >>> this. Just do:<br> >>><br> >>> git branch --set-upstream-to upstream/master<br> >>><br> >>> and I think it should work (though I haven't actually tried it)<br> >>><br> >>> cheers,<br> >>> rog.<br> <br> <br> --<br> Juju-dev mailing list<br> <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br> </div></div></blockquote></div><br></div></div>