From c97d212485d625d93fb6b0f2a46534025e86ac30 Mon Sep 17 00:00:00 2001
From: Thomas Levine <_@thomaslevine.com>
Date: Mon, 29 Feb 2016 03:31:10 +0000
Subject: [PATCH] move more todo to history

---
 HISTORY | 23 +++++++++++++++++++++++
 TODO    | 29 -----------------------------
 2 files changed, 23 insertions(+), 29 deletions(-)

diff --git a/HISTORY b/HISTORY
index ad18171..4b17ce3 100644
--- a/HISTORY
+++ b/HISTORY
@@ -128,6 +128,29 @@ strategies if your setup file gets complicated.
 2. Export a path in your setup file, rewrite your setup file as a shell
    program, and put the rewritten file in your path.
 
+### Run on a file
+Previously you could run urchin only on a directory (and, in turn, all files
+in that directory). Now you can run Urchin on a single file.
+
+This occurred to me when I wanted to run
+
+    urchin test/fast/Unit\ tests/nvm_ls_current
+
+on the nvm tests. I wound up running this instead.
+
+    urchin test/fast/Unit\ tests/ | grep nvm_ls_current
+
+But now I don't have to; the first of these commands will work.
+
+When you run urchin on a file, the test suite root is determined (as with any
+other Urchin call), and the test suite is recursively descended. Setup and
+teardown files are sourced, and everything but the specified test file is
+otherwise ignored.
+
+If you don't explicitly specify the Urchin root with a .urchin file, we
+consider the test suite root directory to be the parent of the file that
+you ran Urchin on.
+
 Version 0.0.6
 ---------------------
 
diff --git a/TODO b/TODO
index 6c5ab3c..1437a74 100644
--- a/TODO
+++ b/TODO
@@ -80,29 +80,6 @@ This is as far as I have gotten with contemplating license changes. For now
 we're sticking with the original MIT-style license, but it's easy to change
 licenses later.
 
-Run on a file
-----------------
-Presently you can run urchin only on a directory.
-It would be neat if you could run it on a file as well.
-
-This occurred to me when I wanted to run
-
-    urchin test/fast/Unit\ tests/nvm_ls_current
-
-on the nvm tests. I wound up running this instead.
-
-    urchin test/fast/Unit\ tests/ | grep nvm_ls_current
-
-The Molly guard would be assessed, and the corresponding setup, setup_dir,
-teardown, and teardown_dir files would be run in the appropriate order.
-
-In order to know how far up the tree to evaluate the setup, &c. files,
-I think it would make sense to require that a ".urchin" file be placed in the
-root of the tests. Urchin would keep going up until it sees this file, and it
-would evaluate the appropriate setup, &c. files from there down to the
-particular test file of interest. We would also use this for testing
-directtories more correctly.
-
 Running automated tasks
 -------------------------
 Urchin might be appropriate for if you have lots of tasks that you want to run
@@ -114,9 +91,3 @@ this sort of thing.
 * Optionally kill tests/jobs after a specific timeout threshold
 * Send output of different tests/jobs to different files for each file
   descriptor (STDOUT, STDERR)
-
-sorting
--------
-How do sort properly?
-
-  printf '- a\n-- a\n--- a\n- b\n-- b\n--- b\n'|sor