41–50 of 50 posts
Earlier quoted context omitted.
> Now I also have a cache for when GitHub goes down (all the time.) Isn't the `.git` a cache for when github goes down? Git keeps all of your history inside your repository; you don't need network access to do anything.
Sort of. I've automated synchronizing it with the GitHub repo, so my local repo may be behind the cached repo. I'm also protected if a repository is deleted/moved/DMCAed.
Earlier quoted context omitted.
http://xkcd.com/1205/ If you pull 10 times a day (conservative for me) then you’ll save ~5 hours over a year.
But couldn't it very well take more than 5 hours to set this up?
Earlier quoted context omitted.
No. I have this enabled and Github closes my connections after a very short period. I use it primarily for SSHing into my cluster of EC2 instances (which does massively speed things up).
Same here. I do a (ssh -fqN -o "StrictHostKeyChecking no" git@bitbucket.org >&/dev/null &) with bitbucket and github in my zshrc and bitbucket stays open but github is getting closed at some point. It used to stay open however.
git merge origin/master
A much preferred workflow.
Hrm, so this isn't about making git 50x faster but fast network communication. > Establishing an SSH connection every time you perform a Git operation costs many round-trips I don't really understand why the author is saying this. The whole point of git is to be distributed and not to push/pull at each commit. That being said, he found something that speeds up his workflow tremendously, so congratulations.
Earlier quoted context omitted.
Sort of. I've automated synchronizing it with the GitHub repo, so my local repo may be behind the cached repo. I'm also protected if a repository is deleted/moved/DMCAed.
What benefits does this provide that a cron job running `git fetch` doesn't?
A 50x speedup is pretty cool in its own right. Kudos. However, I wonder if this isn't treating a symptom versus a root cause. Is saving that 5s round-trip so common in your workflow that you needed to optimize it, and would it be more productive to refactor the app so you and collaborators are working on different files? Also, this has the entirely valuable guidance that pushing to a local server is much faster than…
Hrm, so this isn't about making git 50x faster but fast network communication. > Establishing an SSH connection every time you perform a Git operation costs many round-trips I don't really understand why the author is saying this. The whole point of git is to be distributed and not to push/pull at each commit. That being said, he found something that speeds up his workflow tremendously, so congratulations.
Earlier quoted context omitted.
One that I frequently run into is that if you use SSH tunneling (like -L), you have to specify it the first time you ssh to that machine (i.e. when the ControlMaster is connected) and can't change it later. Using -L on later ssh's to the same machine silently fail, which can be infuriating if you don't realise it's happening. The best you can do at that point is to kill the ControlMaster ssh (disconnecting you across…
You can skip the master and spawn a fresh connection for your tunnel using `-o ControlPath=none`.
ssh> help
Commands:
-L[bind_address:]port:host:hostport Request local forward
-R[bind_address:]port:host:hostport Request remote forward
-D[bind_address:]port Request dynamic forward
-KR[bind_address:]port Cancel remote forward
[EDIT] Apparently, if you have a recent enough version, you can add a forward to the master with `ssh -O forward ...` [1]
[1] http://serverfault.com/questions/237688/adding-port-forwardi...