Search code examples
gitgit-clonegit-remote

Getting the remotes along when pulling a local repo

Common situation:

deployer$ git clone git://gitserver/project.git
deployer$ cd project
deployer$ ./deploy
Lots of errors!
deployer$ hack --until-it-works deploy
deployer$ git commit -m "fixed it" deploy

Oops, now I can't push because deployment-account doesn't have the proper keys. So, back to my own account.

larsmans$ cd /tmp
larsmans$ git clone /path/to/deployed/project
larsmans$ cd project

But now I can't push because the remote is not set to the original clone's remote.

larsmans$ git remote -v
origin  /path/to/deployed/project/ (fetch)
origin  /path/to/deployed/project/ (push)

Can I clone a local directory and get the remotes along? I could easily write a script for this, but maybe Git has it built-in. I couldn't find a relevant option in git-clone(1); --mirror didn't do the trick.

Solution

  • It's not worth scripting, because you do this at most once per project (and person)!

    In fact you almost certainly have a local repository when you get into this situation, don't you? Then the last thing you want to do is a new clone.

    Instead, just git remote add deployed /path/to/deployed/project in your existing regular workspace, git fetch deployed and do whatever you want with deployed/master (refs/remotes/deployed/master) — you can push it directly to origin or check it out or merge it or merge --rebase it or anything.

    Note, that if you can ssh into the server and run git there (which you can if you hack there), you can also git pull from there over the ssh protocol. And it's efficient, because the ssh protocol simply runs git on the remote side and talks to it with the same git protocol, just it's tunnelled through ssh. So on your local machine, you should be able to git remote add deployed host:/path/to/deployed/project; it's preferred to have the host configured in .ssh/config with full host name, user name and public key, but user@host works as well.

    On production server I'd recommend switching back to previous revision, fixing elsewhere and pushing again to limit the downtime. On testing and pre-production this it's of course fine.