David B. Bitton davidbitton

The fastest remote directory rsync over ssh archival I can muster (40MB/s over 1gb NICs)

This creates an archive that does the following:

rsync (Everyone seems to like -z, but it is much slower for me)

a: archive mode - rescursive, preserves owner, preserves permissions, preserves modification times, preserves group, copies symlinks as symlinks, preserves device files.
H: preserves hard-links
A: preserves ACLs

If you are like me you find yourself cloning a repo, making some proposed changes and then deciding to later contributing back using the GitHub Flow convention. Below is a set of instructions I've developed for myself on how to deal with this scenario and an explanation of why it matters based on jagregory's gist.

To follow GitHub flow you should really have created a fork initially as a public representation of the forked repository and the clone that instead. My understanding is that the typical setup would have your local repository pointing to your fork as origin and the original forked repository as upstream so that you can use these keywords in other git commands.

Clone some repo (you've probably already done this step)
```
git clone [email protected]
```

	curl -D cookie1.txt blog.xrmplatform.org/wp-login.php
	# step 1
	# get default cookie of blog and write cookie to cookie1.txt
	# step 2
	# simulate browser Firefox( of course , you can use any browser agent<!--more--> what you want!) "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
	# input your username and also password
	# write new cookie to cookie2.txt
	curl -A "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6" -D cookie2.txt -b cookie1.txt -F log=username -F pwd=password -F testcookie=1 -F wp-submit="Log In" -F redirect_to=blog.xrmplatform.org/wp-admin -F submit=login -F rememberme=forever blog.xrmplatform.org/wp-login.php

	# currently cookie2.txt stored all cookie info

	# We need the latest epel-release for a RHEL/Centos specific cloud-init
	wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
	rpm -Uvh epel-release-6-8.noarch.rpm

	# After this finishes you can build an AMI that will process the user data
	# with cloud-init. You may also be interested in taking a look at the config
	# file at /etc/cloud/cloud.cfg
	yum install cloud-init

	<?php
	/*
	HHVMinfo - phpinfo page for HHVM HipHop Virtual Machine
	Author: _ck_
	License: WTFPL, free for any kind of use or modification, I am not responsible for anything, please share your improvements
	Version: 0.0.6

	* revision history
	0.0.6 2014-08-02 display fix for empty vs zero
	0.0.5 2014-07-31 try to determine config file from process command line (may not always work), style improvements

	var https = require('https');
	var util = require('util');

	exports.handler = function(event, context) {
	console.log(JSON.stringify(event, null, 2));
	console.log('From SNS:', event.Records[0].Sns.Message);

	var postData = {
	"channel": "#aws-sns",
	"username": "AWS SNS via Lamda :: DevQa Cloud",

	# A heavily customized VCL to support WordPress
	# Some items of note:
	# Supports https
	# Supports admin cookies for wp-admin
	# Caches everything
	# Support for custom error html page
	vcl 4.0;
	import directors;
	import std;

	var services = '/services/...'; // Update this with your Slack service...
	var channel = "#aws-deployments" // And this with the Slack channel

	var https = require('https');
	var util = require('util');

	var formatFields = function(string) {
	var
	message = JSON.parse(string),
	fields = [],

	# one or the other, NOT both

	[url "https://github"]
	insteadOf = git://github

	# or

	[url "[email protected]:"]
	insteadOf = git://github