Proposal for rethink of git branching: Patches.

A patch is a series of commits, like a branch.
Unlike a branch, it has a lifecycle. A patch
is created, reviewed and modified, and then
landed.

To start work:

	git/begin my-change

This creates a new patch, which is represented
as a branch.

	          my-change
	            v
	o---o---o---o
		    ^
	           head

Then, edit your code, and commit as normal:


	git/commit

Which gives the following branch

	                my-change
	                   v
	               o---o
	             /
	o---o---o---o
		    ^
	           head

If you want to create a new patch, you can do
it off master, or you can do it off an existing
patch:

	git/begin other-change

And then write your code and commit it:


	                my-change    other-change
	                   v           v
			      o--------o
	                    /
	               o---o
	             /
	o---o---o---o
		    ^
	           head

If you switch back to my-change, and commit,
then other-change gets automatically moved
so that it is based off of the my-change patch:

	                my-change         other-change
	                   v              v
			             o----o
	                            /
	               o---o---o---o
	             /
	o---o---o---o
		    ^
	           head

When you want to send out my-change for reviewm,
you use something like git/submit:

	git/submit 9front@9front.org

Which sends an email. Get your reviews, make some
more changes in response (if needed), and then
land it:

	git/land my-change

This will move your commits from my-change on to
master, delete the branch, and automatically rebase
other-change on top of it:

	                             other-change
	                                  v
			             o----o
	                            /
	o---o---o---o--o---o---o---o

		    ^
	           head