change assignee of issue dd20d3ddc86ee802fe7b15e2c91dc160, None -> seb

08f0d7ee7842c439382816d21ec1dea2/comments/89e04463c36f5cb8d82b66995541c1ce/description

@@ -0,0 +1,5 @@
+Or maybe things that required special handling in the code should live
+directly as fields in the Issue struct?  With their own getter/setter
+API & CLI?
+
+Not sure what's cleaner.

7e2a3a59fb6b77403ff1035255367607/comments/76eee0c6f69981b5c698208725bdd689/description

@@ -0,0 +1,12 @@
+We also need to implement dependency handling, not sure how that should work.
+
+* If we add a dependency to an Issue, to we put the Issue into state
+  Blocked?
+
+* If an Issue is marked Done, do we search all the other issues to see
+  if the Done issue was a dependency, and remove it?
+
+* What happens when the last dependency of an Issue is removed?
+
+(Maybe this comment should be a new issue, not a comment on the parent
+issue)

dd20d3ddc86ee802fe7b15e2c91dc160/assignee

@@ -0,0 +1 @@
+seb

dd20d3ddc86ee802fe7b15e2c91dc160/description

@@ -0,0 +1,10 @@
+store tags as a dir of files, not a file of lines
+
+Currently we store all tags in a file (named `tags`) in the Issue dir.
+The `tags` file has a line per tag.
+
+This is bad because `ent sync` will get a git merge conflict if we add
+or remove a tag near where someone else added or removed a tag.
+
+Better to have a `tags` a directory, with an empty file per tag.
+The filename is the tag.  This use is conflict free in git.

dd20d3ddc86ee802fe7b15e2c91dc160/state

@@ -0,0 +1 @@
+inprogress