Kickstarter is over. Yay!

Today I worked on the bug where `git annex watch` turned regular files
that were already checked into git into symlinks. So I made it check
if a file is already in git before trying to add it to the annex.

The tricky part was doing this check quickly. Unless I want to write my
own git index parser (or use one from Hackage), this check requires running
`git ls-files`, once per file to be added. That won't fly if a huge
tree of files is being moved or unpacked into the watched directory.

Instead, I made it only do the check during `git annex watch`'s initial
scan of the tree. This should be ok, because once it's running, you
won't be adding new  files to git anyway, since it'll automatically annex
new files. This is good enough for now, but there are at least two problems
with it:

* Someone might `git merge` in a branch that has some regular files,
  and it would add the merged in files to the annex.
* Once `git annex watch` is running, if you modify a file that was
  checked into git as a regular file, the new version will be added
  to the annex.

I'll probably come back to this issue, and may well find myself directly
querying git's index.

---

I've started work to fix the memory leak I see when running `git annex
watch` in a large repository (40 thousand files). As always with a Haskell
memory leak, I crack open [Real World Haskell's chapter on profiling](http://book.realworldhaskell.org/read/profiling-and-optimization.html).

Eventually this yields a nice graph of the problem:

[[!img profile.png alt="memory profile"]]

So, looks like a few minor memory leaks, and one huge leak. Stared
at this for a while and trying a few things, and got a much better result:

[[!img profile2.png alt="memory profile"]]

I may come back later and try to improve this further, but it's not bad memory
usage. But, it's still rather slow to start up in such a large repository,
and its initial scan is still doing too much work. I need to optimize
more..