The Vertical Farm: Feeding the World in the 21st Century, by Dickson Despommier

This book was given to me by a happy Git user (Thanks, Michael!) as a gift, picked from my wish list at Amazon.


The book was fascinating and somewhat disappointing at the same time. Perhaps disappointing is not a good word, and I should say somewhat frustrating.

I found that the first half of the main argument of the book very convincing: conventional soil-based agriculture that relies heavily on agro-chemicals (herbicide, insecticide and fertilizer) and causes terrible damage to the environment due to run-off water, is not simply sustainable. The other half of the premise, however, looked rather sketchy, day-dreaming and hand-wavey: multi-story high-tech greenhouses can be built inside city boundaries, and using the state of the art scientific method (e.g. supplying the plants with purified water spiked with necessary nutrients and growing them aeroponically; lighting with OLED that emits only the wavelengths absorbed by chlorophyll; burning plant waste with plasma-arc gassification) sufficient amount of high-quality food can be produced, freeing vast farmland that we have been wasting back to the nature, while reclaiming as much water and energy as possible.


I am reasonably sure that the author has some solid numbers to convince policy people about the benefit and feasibility of his dream, but I found them solely lacking in the book. Here is only one passage with some numbers I remember:

One strawberry farmer who wishes to remain anonymous decided to replace his now destroyed 30 acre farm by constructing a high-tech greenhouse with a 1 acre footprint. Using hydrostackers, he was able to produce the equivalent of 29 acres’ worth of fruit, with year-round production. He elected to return the rest of his farm to its natural setting by simply leaving it alone. Within two years, the understory had returned and the biodiversity of the land improved dramatically.

That is a nice story, but isn't strawberry rather special? It is sufficiently high-value kind of produce that would pay for a farmer to invest in high-tech. If the book had some back-of-the-envelope attempt at some math, like, "To supply a small city of 20,000 people, we would need X tons of grains, Y tons of cabbage, Z tons of ..., and it would need to treat W gallons of black water a year. A vertical farm consisting of N buildings (M stories high) of L sqft footprint would be sufficient for all of the above. The net intake of water and energy, offsetting with the water and energy reclaimed, would be such and such", even if the numbers were qualified with "this is just a back-of-the envelope with my own optimistic assumption that in 5 years technology will sufficiently advance to solve this and that problems", it would have been able to convert me, a mere interested reader, into a believer, somebody who shares the dream.

In the chapter on funding, after discussing that not everything is money and governments will be the likely sources of sponsorship, Dickson alludes to commercial sponsorship possibilities, and there I found this passage:

Google would be my first choice. This giant has an altruistic streak a mile wide. Google could afford to promote the concept with significant financial aid.

This is what made me the most frustrated about the book, because that was exactly what I was feeling while reading earlier parts of the book. Google is a green company; it for example uses many solar photo-voltaic panels (1.6MW), supplying about 30% peak electricity in the four main buildings. Significant number of employees take company shuttles, instead of driving their own cars to work.


If I were to bump into Larry or Sergey at the campus tomorrow and have a chance to chat with them (not likely to happen, as my workplace is on the other side of the campus that is a mile wide), I would love to suggest them that we build an experimental vertical farm near the Mountain View campus, supplying all 20+ cafes and micro-kitchens. Even though the book managed to convert me enough to be very much attracted to the idea, it didn't give me enough to come up with an intelligently-sounding answer to a very basic question, such as "OK, we will go ahead with Dickson's idea—how much space and how much workers do you want?"


Nevertheless, the author's enthusiasm jumps at you from every page, while deep knowledge and experience in his professional area (the author is a microbiologist, ecologist and Professor of Public Health in Environmental Health Sciences at Columbia University) showing through between lines. It was a very pleasant read, and I would highly recommend it to anybody.

Git 1.7.9

The latest feature release Git 1.7.9 is now available at the usual places.

The release tarballs are found at:

    http://code.google.com/p/git-core/downloads/list

Also the following public repositories all have a copy of the v1.7.9 tag and the master branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

As already reported in various places (including lwn.net and Linus Torvalds), the most notable feature in this release is unarguably the improved support for the pull-request based workflow, in which participants can exchange their histories more securely, even over a potentially untrustable hosting service. This is truly an end-to-end support, starting from the inception of a topic branch with its own description, use of the branch description and the message in a signed tag in a pull-request message, use of the message in a signed tag in the resulting merge commit and verification of the signature when reviewing the resulting history (see this for a tutorial).

There also are many other updates that hopefully make working with Git a more delightful experience. Highlights are:

• "Credential helper" support, that allows integration of HTTP authentication with platform-native key-chain implementations;
• New progress eye-candy output for a couple of lengthy operations e.g. fsck;
• I18N framework enabled for both C and scripted Porcelains;
• Improvement in prompted input from an interactive terminal (most notably, reading the username for HTTP authentication);
• You can now run "git checkout -B <current branch> <elsewhere>" to correct the tip of the checked out branch;
• As another step to support large files better, "git add" stores large files directly into a new packfile without having to hold everything in-core at once; and
• "Signed commit" support, that lets a commit object record a GPG signature on it.

 Have fun.

Preparing for the next cycle

While hunting for last-minute embarrasing bugs before the final release of upcoming Git version 1.7.9, those in the Git development community have been busy preparing their own topics to scratch various itches of their own. As we have been in the pre-release feature freeze for about three weeks by now, there have been quite a few such topics, waiting to become part of the release after 1.7.9, being tested in the 'next' branch. I counted 48 patches spanning 23 topics.

Kind	Topics	Patches
Fixes	9	19
UI, Workflows & Features	7	10
Performance	2	6
Internal Implementation	5	13

I've been re-reading them to check their sanity for the past several days, and they all look more or less ready to go. I expect that the next cycle after version 1.7.9 is released will be a short one, just like this cycle leading to 1.7.9 has been.

One of the potentially contentious topic is a change to the git merge command. In the versions up to the upcoming 1.7.9, when the changes from histories being consolidated merge cleanly without conflict, the command records the result without any extra user interaction, using a commit log message that is auto-generated based on the name and contents of the branch being merged.

Linus recently admitted that this is one of the regrettable UI mistakes we made in the early days of Git. This behaviour led too many people to blindly make merge commits that merge into their topic branches, whose purpose is to develop a feature and fix in isolation, of the upstream branch, whose purpose is to integrate assorted topics and move the overall project forward, without justifying why such a merge in a wrong direction was necessary to advance their topics. Of course, git commit --amend command can be used to update the merge commit log message after git merge is done, and the recent git merge command can be given the --edit option to open an editor, but in practice, not many people bother to perform such an extra step only to strive for long term health of the project history.

Just like the git commit command encourages users to explain and justify their non-merge commits by opening an editor and have them describe the commit, the git merge command in the version of Git after the upcoming version 1.7.9,  when used interactively, will open an editor, so that the user can further edit the auto-generated merge commit log message and explain why the merge was made.

Oh, I've also been working on a topic that will get ready far in the future, but that will be another article.

Git 1.7.7.6, 1.7.8.4 and 1.7.9-rc2

Three releases are out on the same day, which is not very unusual for me.

The two maintenance releases are primarily to correct an obscure bug introduced in 1.7.7.1 when you use wildcard pathspec to run "git diff $commit" command.

On the 'master' front, the second release candidate seems to be quite solid and includes the how-to document I earlier posted a preview for.

Hopefully we can have an uneventful final 1.7.9 release by the end of this month.

Using signed tag in pull requests

[edit: This is where the backstory behind this new feature begins.]
(This is a preview of an howto article meant to be distributed as part of upcoming v1.7.9 release of Git).
A typical distributed workflow using Git is for a contributor to fork a project, build on it, publish the result to her public repository, and ask the "upstream" person (often the owner of the project where she forked from) to pull from her public repository. Requesting such a "pull" is made easy by the git request-pull command.

Earlier, a typical pull request may have started like this:

 The following changes since commit 406da78032179...:

   Froboz 3.2 (2011-09-30 14:20:57 -0700)

 are available in the git repository at:

   example.com:/git/froboz.git for-xyzzy

followed by a shortlog of the changes and a diffstat.

The request was for a branch name (e.g. for-xyzzy) in the public repository of the contributor, and even though it stated where the contributor forked her work from, the message did not say anything about the commit to expect at the tip of the for-xyzzy branch. If the site that hosts the public repository of the contributor cannot be fully trusted, it was unnecessarily hard to make sure what was pulled by the integrator was genuinely what the contributor had produced for the project. Also there was no easy way for third-party auditors to later verify the resulting history.

Starting from Git release v1.7.9, a contributor can add a signed tag to the commit at the tip of the history and ask the integrator to pull that signed tag. When the integrator runs git pull, the signed tag is automatically verified to assure that the history is not tampered with. In addition, the resulting merge commit records the content of the signed tag, so that other people can verify that the branch merged by the integrator was signed by the contributor, without fetching the signed tag used to validate the pull request separately and keeping it in the refs namespace.

This document describes the workflow between the contributor and the integrator, using Git v1.7.9 or later.

A contributor or a lieutenant

After preparing her work to be pulled, the contributor uses git tag -s to create a signed tag [1]:

 $ git checkout work
 $ ... "git pull" from sublieutenants, "git commit" your own work ...
 $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work

and pushes the tag out to her publishing repository [2]. There is no need to push the work branch or anything else:

 $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy

Then the contributor prepares a message to request a "pull":

 $ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt

The arguments are:

1. the version of the integrator’s commit the contributor based her work on;
2. the URL of the repository, to which the contributor has pushed what she wants to get pulled; and
3. the name of the tag the contributor wants to get pulled (earlier, she could write only a branch name here).

The resulting msg.txt file begins like so:

 The following changes since commit 406da78032179...:

   Froboz 3.2 (2011-09-30 14:20:57 -0700)

 are available in the git repository at:

   example.com:/git/froboz.git tags/frotz-for-xyzzy

 for you to fetch changes up to 703f05ad5835c...:

   Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)

 -----------------------------------------------
 Completed frotz feature
 -----------------------------------------------

followed by a shortlog of the changes and a diffstat. Comparing this with the earlier illustration of the output from the traditional git request-pull command, the reader should notice that:

1. The tip commit to expect is shown to the integrator; and
2. The signed tag message is shown prominently between the dashed lines before the shortlog.

The latter is why the contributor would want to justify why pulling her work is worthwhile when creating the signed tag. The contributor then opens her favorite MUA, reads msg.txt, edits and sends it to her upstream integrator.

Integrator

After receiving such a pull request message, the integrator fetches and integrates the tag named in the request, with:

 $ git pull example.com:/git/froboz.git/ tags/frotz-for-xyzzy

This operation will always open an editor to allow the integrator to fine tune the commit log message when merging a signed tag. Also, pulling a signed tag will always create a merge commit even when the integrator does not have any new commit since the contributor’s work forked (i.e. fast forward), so that the integrator can properly explain what the merge is about and why it was made.

In the editor, the integrator will see something like this:

 Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/

 Completed frotz feature
 # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
 # gpg: Good signature from "Con Tributor <nitfol@example.com>"

provided if the signature in the signed tag verifies correctly. Notice that the message recorded in the signed tag "Completed frotz feature" appears here, and again that is why it is important for the contributor to explain her work well when creating the signed tag.

As usual, the lines commented with # are stripped out. The resulting commit records the signed tag used for this validation in a hidden field so that it can later be used by others to audit the history. There is no need for the integrator to keep a separate copy of the tag in his repository (i.e. git tag -l won’t list frotz-for-xyzzy tag in the above example), and there is no need to publish the tag to his public repository, either.

After the integrator responds to the pull request and her work becomes part of the permanent history, the contributor can remove the tag from the publishing repository, if she chooses, in order to keep the tag namespace of her public repository clean, with:

 $ git push example.com:/git/froboz.git :frotz-for-xyzzy

Auditors

The --show-signature option can be given to git log or git show and shows the verification status of the embedded signed tag in merge commits created when the integrator responded to a pull request of a signed tag.

A typical output from git show --show-signature may look like this:

 $ git show --show-signature
 commit 02306ef6a3498a39118aef9df7975bdb50091585
 merged tag 'frotz-for-xyzzy'
 gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB
 gpg: Good signature from "Con Tributor <nitfol@example.com>"
 Merge: 406da78 703f05a
 Author: Inte Grator <xyzzy@example.com>
 Date:   Tue Jan 17 13:49:41 2012 -0800

     Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/

     Completed frotz feature

     * tag 'frotz-for-xyzzy' (100 commits)
       Add tests and documentation for frotz
       ...

There is no need to fetch and keep a signed tag like frotz-for-xyzzy that is used for frequent "pull" exchange in the long term just for such auditing purposes, as the signature is recorded as part of the merge commit.

Footnotes

1 This example uses the -m option to create a signed tag with just a single liner message, but this is for illustration purposes only. It is advisable to compose a well-written explanation of what the topic does to justify why it is worthwhile for the integrator to pull it, as this message will eventually become part of the final history after the integrator responds to the pull request.

2 The example uses plus at the beginning of +frotz-for-xyzzy to allow forcing the update of a tag, as the same contributor may want to reuse a signed tag with the same name after the previous pull request has already been responded to.

Git 1.7.9-rc1 is out

This is supposed to be feature complete for the upcoming release, and we are now in the pre-release feature freeze from now on (see tinyurl.com/gitcal for the release schedule calendar).

Minor and obvious bug fixes and documentation updates are appreciated, but the primary focus for the coming few weeks will be on regression hunting and fixes.

I also suspect that the documentation to the new features may still be sketchy, and we may want to fix that by the final release. The "pulling signed tag" topic, for example, may want a new article in Documentation/howto/ area, perhaps lifting some text from here. I may try to do an initial draft over the long weekend.

Git 1.7.9-rc0 and 1.7.8.3

I just tagged Git 1.7.9-rc0, which is the zeroth release candidate in the sense that it is supposed to be almost feature complete and marks the beginning of feature freeze.

We have achieved quite a lot during this cycle. All the new things that we initially listed that we want to have are in it:

• Better and more auditable communication in pull based workflow by supporting electronically signed pull requests that records more meaningful branch description;
• More pleasant end-user experience by providing credential helper API to allow platform native keychain implementations to supply authentication material during "git push" and "git pull";
• i18n of messages out of the end-user facing programs; and
• Better large-contents support.

Even though we didn't originally plan to, this also includes support for signed commits as a part of the first topic in the above list.


I also tagged 1.7.8.3 from the tip of the maintenance track. The fixes in this maintenance release are all included in 1.7.9-rc0 release.

Adding finishing touches to the "pulling signed tags" topic

[edit: a how-to article will be included in the 1.7.9 release; here is a preview]

One of the more important topics scheduled for the upcoming Git 1.7.9 release is for a contributor to ask the integrator to pull a signed tag and for the integrator to merge such a signed tag to the history. This has already been used in the field by Linus but there wasn't a good automated way to view and verify the signature after such a merge is made.

Until now.

I started working on a follow-up topic to teach "git log --show-signature" about these merge commits, and have a working code in today's proposed updates branch ('pu'). Hopefully we can have this feature, possibly with some clean-ups, in the same 1.7.9 release, if we get enough help from the contributors in the development community.

Knock wood...