Fork and clone in one command

[krlmlr]

Examples:

hub clone -f user/repo
hub clone --fork user/repo

Forks and then clones, adding both the upstream and own repos as reference. I prefer my own repo to be called origin (since this is usually the only one I'm allowed to push to), and the remote repo to be called by the other user name or upstream.

hub fork user/repo

Should work outside a repository. Perhaps easier than enhancing clone.

[mislav]

I dig hub fork user/repo. Although hub expects the upstream remote to be named "origin" and keeps a convention of naming forks by their GH username, so your fork's remote would be named "krimir"

[krlmlr]

@mislav: I think the following will work for me, once it's implemented:

hub fork user/repo
hub clone repo
cd repo
hub remote add user/repo

Currently it's slightly more complicated:

hub clone user/repo
cd repo
hub fork
hub remote add myself
git remote rename origin user
git remote rename myself origin
git pull --all

Also, that's exactly how I would expect hub clone --fork to work, perhaps with another option --as-origin.

[hauleth]

The origin shouldn't be changed as it is used in other commands like pull-request.

[krlmlr]

@hauleth: Still, if I hub clone a repo that I have already forked using the GitHub website, what will its remote be called?

[mislav]

If you clone your fork, the remote will be named "orgin" and will point to your fork. I suggest cloning the canonical repo instead and calling hub fork to add an extra remote pointing to your fork.

[krlmlr]

@mislav: You mean, hub clone --fork? :-)

If I clone the canonical repo, I have to wait (or enter commands blindly) until I can issue the fork command.

[mislav]

clonefork() {
  hub clone "$1"
  cd "${1##*/}"
  hub fork
}

# in your shell:
$ clonefork user/repo

Still have to think about hub clone --fork or hub fork user/repo.

[olivierlacan]

If it's at all relevant, I had never used fork before and I tried to do: git fork bundler/bundler assuming that would create a fork on my GitHub account, use that as origin and set bundler/bundler as my upstream remote.

Having to this felt backwards and overly complex:

git clone bundler/bundler
cd bundler
git fork
git remote rename origin upstream
git remote rename olivierlacan origin

I'm of course assuming this origin => fork & upstream => canonical repo is widespread.

[robdodson]

Would it be possible to make upstream/origin configurable in hub? I also use the upstream (canonical), origin (personal fork) pattern.

[vermiculus]

@robdodson See also #720

[olivierlacan]

@mislav Any new thoughts on this?

Reached for git fork org/repo again today and was completely confused (it's been a while) that I had to do this:

$ git fork evanphx/benchmark-ips
fatal: Not a git repository

... pause for confusion, look up syntax ...

$ git clone evanphx/benchmark-ips
Cloning into 'benchmark-ips'...
...
$ cd benchmark-ips/
$ git fork
Updating olivierlacan
From https://github.com/evanphx/benchmark-ips
 * [new branch]      clearer-compare -> olivierlacan/clearer-compare
 * [new branch]      master          -> olivierlacan/master
new remote: olivierlacan
$ git remote rename origin upstream
$ git remote rename olivierlacan origin
$ git remote -v
origin  git@github.com:olivierlacan/benchmark-ips.git (fetch)
origin  git@github.com:olivierlacan/benchmark-ips.git (push)
upstream    https://github.com/evanphx/benchmark-ips.git (fetch)
upstream    https://github.com/evanphx/benchmark-ips.git (push)

[mislav]

@olivierlacan It makes absolute sense that git fork org/repo should ideally clone org/repo as upstream remote, fork it, and add an extra origin remote for YOURNAME/repo.

PRs welcome!

[apjanke]

It makes absolute sense that git fork org/repo should ideally clone org/repo as upstream remote, fork it, and add an extra origin remote for YOURNAME/repo.

What do you think about similar functionality for hub clone for when you're cloning a repo of yours that is an existing fork of a canonical repo?

For example, I work on several machines, and when I'm setting up a new machine, I have to clone my forked repos, and then go in and add upstream remotes in each of them.

How about, when doing a hub clone <repo> or hub clone <user>/<repo>, it still creates the specified repo as the origin remote, and then checks to see if that repo is a fork, and if so, adds an upstream remote pointing to the root of the fork tree?

Then maybe doing git fork org/repo when you have an existing local clone could be seen as just adding the upstream remote in the same manner. Maybe #1411 could be folded in to that.