update-indices doesn't deal with amends well

[wincent]

Noticed this in local development testing:

1. Start with long, indexed history.
2. Add a commit a.
3. Run update-indices; see only that commit get indexed.
4. Amend a, producing a'.
5. Run update-indices; recoil in horror as entire history gets reindexed all over again.

So basically what it's doing here is see that a, the last-indexed hash, is not an ancestor of a', so it goes all the way back to the beginning of the history.

What we would need to do here to make this entirely robust is make the indexer aware not only of the last-indexed hash, but actually maintain a stack of them. It would then need to effectively rollback the effect of a on the index and then re-apply a' on top of it. That should be possible in prod and in dev only because the "content" repo doesn't get replaced per-deploy; it's just one long-lived thing.

In addition to maintaining Redis-backed stack, may need to use reflog in order to figure out what actually happened.

Alternative solution: disallow amends on indexed commits (require separate commit on top).

[wincent]

See #64 for discussion of adding a pre-commit hook to disallow bad things (such as amending an already-published commit).

[wincent]

Going to close this as my pre-commit hook is probably good enough.