how to update dependencies.tsv

[Nate Finch]

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?
On Oct 31, 2014 11:48 AM, "Eric Snow" <eric.snow at canonical.com> wrote:

> On Fri, Oct 31, 2014 at 2:11 AM, roger peppe <roger.peppe at canonical.com>
> wrote:
> > On 30 October 2014 14:34, Eric Snow <eric.snow at canonical.com> wrote:
> >> On Thu, Oct 30, 2014 at 4:40 AM, roger peppe <roger.peppe at 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.
>
> >
> > 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141031/969b66fc/attachment-0001.html>