3

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.

Improve this question

1 Answer 1

Reset to default
4

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Actually, this happens quite often -- we deploy on lots of hosts, sometimes multiple times to test features. I like your ideas, but in my environment (small team in large academic institution working on prototype software) pulling from deployments to my workstation requires negotiating firewall exceptions or larger NFS quota with systems administration.
@larsmans: I beg to differ. If you can ssh into that station and run git there (you apparently can), you can pull from it using the ssh protocol.
Ah, I hadn't thought of that! I was under the impression that you'd need a specialized server to even get SSH to work.
@larsmans: The pull over ssh just invokes ssh host git upload-pack /path/to/repo. The same command is also used by local pull. The other protocol servers are also part of standard git, git daemon (git protocol), git update-server-info (dumb http) and git-http-backend (smart http), but ssh is obviously most convenient for any server you have ssh access to.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.