Change crappy nonstandard name 'upstream' to nice standard name 'origin'

[andralex]

It's all my fault.

Back in the day when we were setting up things at github, someone convinced me everybody uses "upstream" as the mothership repository name. I've gotten zero evidence ever since, but things have remained that way in the scripts.

I don't want to puzzle newcomers by using an unusual naming scheme "just because we do it that way". In the spirit of doing things right and not accumulating cruft I'm submitting this.

[andralex]

The inconvenience for existing users who have used this script in the past is they'd need to run:

git remote rename upstream origin

In case their own fork was called origin, they'd need to rename that first, i.e.:

git remote rename origin myfork
git remote rename upstream origin

[MartinNowak]

How about detecting the existing remote names (using git remote -v | grep '^upstream.*D-Programming-Language') and the message from your previous comment?

[andralex]

I could do that but I hope to remove all Band-Aid in one swoop.

[WalterBright]

Uh-oh, I sense another github disaster coming.

[dnadlinger]

@WalterBright: Why would you do so?

I think this commit was merged rather hastily, but I don't see how GitHub would really be related to the situation.

[MartinNowak]

I think this commit was merged rather hastily, but I don't see how GitHub would really be related to the situation.

As Andrei said, we're using a really weird naming scheme, so it's good to change this.

[yebblies]

I'm using this setup (and AFAIK so is everyone else)
git remote add origin git@github.com:yebblies/dmd.git
git remote add upstream git@github.com:D-Programming-Language.git
ie my fork is origin (https://help.github.com/articles/fork-a-repo)

[dnadlinger]

@andralex, @MartinNowak: upstream certainly isn't a "crappy nonstandard name" from an "unusual naming scheme", see e.g. the GitHub help article on forking a repository: https://help.github.com/articles/fork-a-repo. It's using it as the main remote name that might be unusual, but I don't see how that would justify outright disregarding backwards-compatibility for all current users of the script.

I'm not sure that there are even many people using the script at all, though, so I'm not doubting that merging this might be a good idea. But why the rush on one of the few open pull requests that are actually somewhat controversial?

[andralex]

The problem is people often just clone git@github.com:D-Programming-Language.git first, and have it as the name origin. Chronologically that must always predate the creation of the fork on it.

[andralex]

I think https://help.github.com/articles/fork-a-repo has an unusual sequence (fork on the web, THEN initiate any cloning etc - who does that?)

[andralex]

@klickverbot let's just go through this once. We're not talking about our user base but instead our contributor base, which may in fact be helped in the long term.

[yebblies]

There is a much better solution to this: make the script explicitly update from git://github.com/D-Programming-Language/$project.git. You don't need a named remote in order to pull.

I think https://help.github.com/articles/fork-a-repo has an unusual sequence (fork on the web, THEN initiate any cloning etc - who does that?)

Github does that. Deviating from what github recommends is going to make life harder, not easier.

We're not talking about our user base but instead our contributor base, which may in fact be helped in the long term.

If our contributors can't work out how to rename a remote, they should learn git before contributing.

[dnadlinger]

@andralex: It's usually how I go about cloning the source code of projects I intend to contribute to. Well, at least how I did before the hub command line tool came along.

Also, I realize that we are talking about (potential) contributors, but that's exactly why I'd be cautious about any changes that might cause unnecessary annoyance to existing contributors.

[andralex]

There is a much better solution to this: make the script explicitly update from git://github.com/D-Programming-Language/$project.git. You don't need a named remote in order to pull.

That's a good idea.

I think https://help.github.com/articles/fork-a-repo has an unusual sequence (fork on the web, THEN initiate any cloning etc - who does that?)

Github does that. Deviating from what github recommends is going to make life harder, not easier.

I was asking which person. My perception is that people first clone the original repo (and build, look at the code etc) before getting animated with the desire to push code. I don't think that article is authoritative at all, it's just for noobs.

We're not talking about our user base but instead our contributor base, which may in fact be helped in the long term.

If our contributors can't work out how to rename a remote, they should learn git before contributing.

That wasn't the problem. The problem was "why the heck do they assume I called the repo upstream?" From that angle cloning with no remote alias is better, I'll do that.

[yebblies]

That wasn't the problem. The problem was "why the heck do they assume I called the repo upstream?" From that angle cloning with no remote alias is better, I'll do that.

Ok. While you're at it you should probably change git pull to git pull --ff-only.

[andralex]

@yebblies for --tags too?

[yebblies]

No, just the normal pull.

[andralex]

#100 rox

[quickfur]

Huh, what? I just got an email from @andralex to rename my repo, but I don't see what this pull has to do with anything. I just forked the tools repo (i.e., this one) and checked out my fork, and set 'upstream' to be https://github.com/D-Programming-Language/tools.git (i.e., back here), and it has worked ever since.

So, can somebody please explain what's all this ado about? What am I supposed to do?

[yebblies]

@quickfur Exactly what you did. The problem was this script forced that layout when not everybody followed it. It's now changed to not rely on the dpl repo being called upstream, so everyone should be happy.

[quickfur]

Oh. Heh, well I never actually use that script, so I guess it doesn't apply to me?

[yebblies]

Correct.

[llucax]

I might had some influence in calling the blessed repo upstream, at least I do that and I never read the GitHub help on cloning. The reason is, when you clone form the blessed repo and it becomes origin, then you push by default to it. In a "triangular workflow" (as github has with the pull requests), this is not what you want. Hence you usually use your fork as origin. I guess this is why the GH dudes are recommending this too.

Since git 1.8.3 support for the triangular workflow was introduced by adding the config variable remote.pushdefault. So now what you would do is to have the blessed repo as origin (as it feels more natural), and your fork with another name (like myfork) and then set git config remote.pushdefault myfork. Then you'll pull by default from the blessed repo and you push by default to your fork.

I plan to introduce support for the triangular workflow right out of the box in the clone command for the git-hub tool in the next release.

[andralex]

@llucax terrific stuff, thanks. I've added git config remote.pushdefault myfork throughout.