how to update dependencies.tsv

[Andrew Wilkins]

On Mon, Nov 10, 2014 at 6:02 AM, Tim Penhey <tim.penhey at canonical.com>
wrote:

> I'm more interested in a solution that works for everyone rather than
> pointing fingers.
>
> Given that our current docs suggest specifying origin to personal repo,
> and upstream to the juju ones, is there any way we can configure the
> local repo such that when we say 'git fetch' it fetches from upstream
> rather than origin?
>

>From "git help fetch":

    "When no remote is specified, by default the origin remote will be used,
    unless there’s an upstream branch configured for the current branch."

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:

$ # initially no upstream set
$ git fetch -v
>From github.com:axw/juju
(noise)

$ git branch -vv | grep \*
* icantbelieveitsnotmaster                              fc54097 Merge pull
request #1070 from axw/lp1362072-azure-verify-credentials
$ git remote -v
origin git at github.com:axw/juju.git (fetch)
origin git at github.com:axw/juju.git (push)
upstream git at github.com:juju/juju.git (fetch)
upstream no-pushing (push)
$ git branch --set-upstream-to upstream/master
Branch icantbelieveitsnotmaster set up to track remote branch master from
upstream.
$ git branch -vv | grep \*
* icantbelieveitsnotmaster                              fc54097
[upstream/master] Merge pull request #1070 from
axw/lp1362072-azure-verify-credentials

$ # git fetch will now go to the right place
$ git fetch -v
(noise)
>From github.com:juju/juju
(noise)

Cheers,
Andrew

Failing that, I'd suggest that we change our docs so we don't break our
> contributors.
>
> The problem is that right now, someone following our docs will get a
> broken experience.
>
> Tim
>
> On 30/10/14 23:40, roger peppe wrote:
> > On 30 October 2014 09:47, Nate Finch <nate.finch at 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.peppe at canonical.com>
> wrote:
> >>>
> >>> On 29 October 2014 21:03, Tim Penhey <tim.penhey at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141110/3dd8a9c3/attachment.html>