Menu
I start up Ubuntu Linux, open a terminal, edit some code, and happily execute
git push origin master
However, after some period of time (sometimes 30 mins, sometimes a few hours), the exact same command will hang (no output at all).
When I try
ssh -v [email protected]
I get the following response:
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /home/avitus/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master
And then it hangs again. It seems as though I can no longer use SSH to git once I've SSH'ed to another server. Any ideas how to fix this? It is killing me having to reboot each time.
Update:
The problem goes away when I remove the following two lines (intended to facilitate connection sharing) from ~/.ssh/config
ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r
454
You need to use git pull and resolve the difference between your local changes and the remote changes before you can git push . There is still a commit in the remote branch initializing the repo that may not be in your local version.
Even if you did small changes, some internal things might cause git to push a lot more data. Have a look at git gc. It cleans up your local repository and might speed up things, depending on you issue. Backup strongly advised.
failed to push some refs to errors are often caused when changes are not committed before pushing, issues with Git pre-push hook, incorrect branch name, or the local repository not being in sync with the Git repository.
Typically pushing and pulling a few times a day is sufficient. Like @earlonrails said, more frequent pushes means less likelihood of conflicting changes but typically it isn't that big a deal. Think of it this way, by committing to your local repository you are basically saying "I trust this code. It is complete.
Just turning my guess from a comment into an answer...
The last line in the output of ssh -v:
debug1: auto-mux: Trying existing master
... tells you that SSH has been configured to look for an existing SSH connection to reuse. I suspect that this existing connection eventually gets stuck in some way, which would explain the behaviour you're seeing.
This connection sharing facility is described in the ControlMaster section of the ssh_config(5) man page. Essentially the "master" SSH session creates a socket in /tmp which later sessions can connect to instead of having to go through the potentially length authentication step again. You have this option set to auto, which means that this socket will be created and used automatically.
65
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
