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 orupstream
.
hub fork user/repo
Should work outside a repository. Perhaps easier than enhancing
clone
.
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"
@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
.
The origin
shouldn't be changed as it is used in other commands like pull-request
.
@hauleth: Still, if I hub clone
a repo that I have already forked using the GitHub website, what will its remote be called?
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.
@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.
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
.
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.
Would it be possible to make upstream/origin configurable in hub? I also use the upstream (canonical), origin (personal fork) pattern.
@robdodson See also #720
@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 [email protected]:olivierlacan/benchmark-ips.git (fetch)
origin [email protected]:olivierlacan/benchmark-ips.git (push)
upstream https://github.com/evanphx/benchmark-ips.git (fetch)
upstream https://github.com/evanphx/benchmark-ips.git (push)
@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!
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.
Most helpful comment
@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: