hub cherry-pick (can) fail(s) if remote already exists #444

reitblatt opened this Issue Dec 5, 2013 · 3 comments


None yet

3 participants

bash-3.2$ hub --version
git version
hub version 1.10.6

Previously handled pull-requests from this fork, went to cherry-pick a commit:

bash-3.2$ hub cherry-pick
fatal: remote adferguson already exists.

Also fails with github markdown:

hub cherry-pick adferguson@d952e26028661b3e15d7b84610bc8104b17de812
fatal: remote adferguson already exists.

Removing the remote and then cherry-picking works. Can't seem to force it to reproduce.

mislav commented Dec 21, 2013

I think this can happen if you had a "adferguson" remote that does not point to repo. It would then try to add a new "adferguson" remote and fail like your case above.

Not sure if I want to fix this. I found myself never using cherry-pick anymore since it pollutes my local git repo with remotes. I use hub am <URL> instead. I might deprecate cherry-pick in favor of am, or even implement cherry-pick like am.


@mislav instead of adding a permanent remote, could it add a temporary one with random characters, fetch, cherry pick, then delete it? Or if one exists with a different url append a number to the end until no collisions are found such as adferguson1?

mislav commented Dec 2, 2014

We will probably go with the approach I described in my above comment: avoiding adding the remote & git pull and just go with the hub am approach: download the patch for the commit directly from GitHub API and apply it.

@mislav mislav added the bug label Dec 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment