doc/todo/git_repo_tracking___40__not_storage__41__.mdwn

@@ -0,0 +1,8 @@
+If git-annex tracked some information like the repo's remotes, current checkout hash, whether there are uncommitted modifications, branch states, stash state, etc., it seems like it could treat the repo similar to a URL registered for downloading a key. (I've seen the previous threads and agree git-annex should not "store" the repo). With such tracking, I think git-annex could support compelling workflows for managing code/project directories.
+
+A few possibilities:
+
+- Drop a repo for space if the current commit is available in at least N remotes (and all of the repo state is pushed/clean).
+- Create branches or tags in an annex that collect a set of version-compatible checkouts for related projects. The commit/tag messages provide a natural place for meta-commentary
+- Save and version files that aren't quite junk but don't belong *in* a repo (logs, dumps, backups, editor project/workspace files, notes/to-do lists, build-artifacts, test-coverage/linter stat databases, shell history) alongside the repo, making it easier to have a consistent environment for working on one project across multiple systems.
+- Make separate system-specific "master" branches for the main projects directory on each system, then edit and push changes from any other. For example, prep the projects directory on an infrequently-used laptop from your desktop and push/pull the changes.