how to update dependencies.tsv

[Tim Penhey]

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?

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.